版权

Copyright

作者和出版商在编写本书时已谨慎行事，但不作任何形式的明示或暗示的保证，也不对错误或遗漏承担任何责任。对于与使用此处包含的信息或程序有关或由此引起的附带或间接损害，我们不承担任何责任。

The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

出版商： John Wait

主编：Don O'Hagan

收购编辑： Paul Petralia

市场经理： Chris Guzikowski

执行编辑：John Fuller

项目编辑：Julie Nahil

制造业买家： Carol Melville

Publisher: John Wait

Editor in Chief: Don O'Hagan

Acquisitions Editor: Paul Petralia

Marketing Manager: Chris Guzikowski

Managing Editor: John Fuller

Project Editor: Julie Nahil

Manufacturing Buyer: Carol Melville

当批量订购用于批量购买或特价销售时，出版商会为这本书提供极好的折扣，其中可能包括电子版本和/或定制封面以及特定于您的业务、培训目标、营销重点和品牌兴趣的内容。欲了解更多信息，请联系：

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

美国企业和政府销售

（800） 382-3419

corpsales@pearsontechgroup.com

     U. S. Corporate and Government Sales

     (800) 382-3419

     corpsales@pearsontechgroup.com

对于美国境外的销售，请联系：

For sales outside the U. S., please contact:

国际销售

international@pearsoned.com

     International Sales

     international@pearsoned.com

请访问我们的网站：www.phptr.com

Visit us on the Web: www.phptr.com

美国国会图书馆出版物编目数据：

Library of Congress Cataloging-in-Publication Data:

拉曼，克雷格。

应用 UML 和模式：面向对象的分析和设计以及

迭代开发简介 / Craig Larman。第 3 版，

p. cm.

包括参考书目和索引。

ISBN 0-13-148906-2 （alk. paper）

1.面向对象的方法（计算机科学） 2.UML（计算机科学） 3.系统

分析。4. 系统设计。I. 标题。



QA76.9.O35 L37 2004

005.1'17--dc22 2004057647

Larman, Craig.

    Applying UML and patterns: an introduction to object-oriented analysis and design and

    iterative development / Craig Larman. 3rd ed.

        p. cm.

        Includes bibliographical references and index.

        ISBN 0-13-148906-2 (alk. paper)

        1. Object-oriented methods (Computer science) 2. UML (Computer science) 3. System

    analysis. 4. System design. I. Title.



    QA76.9.O35 L37 2004

    005.1'17--dc22                                                            2004057647

版权所有 © 2005 Pearson Education， Inc.

Copyright © 2005 Pearson Education, Inc.

保留所有权利。在美国印刷。本出版物受版权保护，在以任何形式或任何方式（电子、机械、影印、录制或类似方式）进行任何禁止的复制、存储在检索系统中或传输之前，必须获得出版商的许可。有关权限的信息，请写信至：

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:

Pearson Education， Inc.

权利和合同部

One Lake Street

Upper Saddle River， NJ 07458

Pearson Education, Inc.

Rights and Contracts Department

One Lake Street

Upper Saddle River, NJ 07458

本书中提及的所有产品或服务均为其各自公司或组织的商标或服务标志。

All products or services mentioned in this book are the trademarks or service marks of their respective companies or organizations.

引用致谢：

Quote acknowledgments:

保罗·埃尔多斯（Paul Erdos）：摘自保罗·霍夫曼（Paul Hoffman）的《只爱数字的人》（The Man Who Only Loved Numbers）。

H.G. Wells：经 A.P. Watt Ltd. 许可使用。代表 H.G. Wells 遗产的执行人。

Paul Erdos: From "The Man Who Only Loved Numbers" by Paul Hoffman.

H.G. Wells: Used by permission of A.P. Watt Ltd. On behalf of the Executors of the Estate of H.G. Wells.

在美国马萨诸塞州韦斯特福德的 Courier 用再生纸印刷的文本

Text printed in the United States on recycled paper at Courier in Westford, Massachusetts

2004 年 10 月首次印刷

First printing, October 2004

奉献

Dedication

对于 Julie、Haley 和 Hannah

For Julie, Haley, and Hannah

感谢你们的爱和支持。

Thanks for the love and support.

对应用 UML 和模式的赞誉

Praise for Applying UML and Patterns

“这个版本包含了拉曼一贯的准确和深思熟虑的写作。这是一本非常好的书，做得更好。

Alistair Cockburn，作者，《编写有效的用例和幸存的 OO 项目》

"This edition contains Larman's usual accurate and thoughtful writing. It is a very good book made even better."

Alistair Cockburn, author, Writing Effective Use Cases and Surviving OO Projects

“人们经常问我哪本书最适合向他们介绍 OO 设计的世界。自从我遇到它以来，应用 UML 和模式一直是我毫无保留的选择。

Martin Fowler，《UML Distilled and Refactoring》作者

"People often ask me which is the best book to introduce them to the world of OO design. Ever since I came across it Applying UML and Patterns has been my unreserved choice."

Martin Fowler, author, UML Distilled and Refactoring

“这本书将 UML 逐渐引入为一种直观的语言，用于指定对象分析和设计的工件，从而使 UML 的学习变得有趣和实用。这是由专家从业者编写的对 UML 和对象方法的精彩介绍。

Cris Kobryn，UML 修订任务组和 UML 2.0 工作组主席

"This book makes learning UML enjoyable and pragmatic by incrementally introducing it as an intuitive language for specifying the artifacts of object analysis and design. It is a well written introduction to UML and object methods by an expert practitioner."

Cris Kobryn, Chair of the UML Revision Task Force and UML 2.0 Working Group

“很少有人有解释事情的诀窍。很少有人仍然精通软件分析和设计。Craig Larman 两者兼而有之。

John Vlissides，《设计模式和模式剖面线》作者

"Too few people have a knack for explaining things. Fewer still have a handle on software analysis and design. Craig Larman has both."

John Vlissides, author, Design Patterns and Pattern Hatching

按主要主题划分的内容

Contents by Major Topics

这本书逐步介绍一个主题，随着案例研究的展开，分为多个章节。这很有用，但它引入了一个问题：如何找到有关主要主题（例如 OO 设计）的大多数材料？索引是一种解决方案，但粒度很细;此列表提供了另一个。

This book introduces a topic incrementally, spread out over chapters as the case studies unfold. That's useful, but it introduces a problem: How can you find most material on a major subject (e.g., OO Design)? The Index is one solution, but fine-grained; this listing provides another.

敏捷实践

Agile Practices

什么是敏捷建模？30

What is Agile Modeling? 30

什么是 Agile UP？31

What is an Agile UP? 31

敏捷建模和轻量级 UML 绘图 214

Agile Modeling and Lightweight UML Drawing 214

有关迭代开发和敏捷项目管理的更多信息 673

More on Iterative Development and Agile Project Management 673

建筑

Architecture

逻辑体系结构和 UML 封装图 197

Logical Architecture and UML Package Diagrams 197

建筑分析 541

Architectural Analysis 541

逻辑架构优化 559

Logical Architecture Refinement 559

包装设计 613

Package Design 613

记录架构：UML & N+1视图模型655

Documenting Architecture: UML & the N+1 View Model 655

域建模

Domain Modeling

域模型 131

Domain Models 131

Domain Layer 和 Domain Model 之间有什么关系？206 元

What's the Relationship Between the Domain Layer and Domain Model? 206

域模型优化 507

Domain Model Refinement 507

把握

GRASP

GRASP：设计具有职责的对象 271

GRASP: Designing Objects with Responsibilities 271

GRASP：更多具有职责的对象 413

GRASP: More Objects with Responsibilities 413

使用 Polymorphism 和 Do It Myself 处理付款 600

Handling Payments with Polymorphism and Do It Myself 600

示例：大富翁 607

Example: Monopoly 607

GoF 设计模式

GoF Design Patterns

什么是模式？278 元

What are Patterns? 278

应用 GoF 设计模式 435

Applying GoF Design Patterns 435

更多使用 GoF Patterns 进行对象设计 579

More Object Design with GoF Patterns 579

使用模式设计持久性框架 625

Designing a Persistence Framework with Patterns 625

迭代开发

Iterative Development

迭代、进化和敏捷 17

Iterative, Evolutionary, and Agile 17

进化要求 53

Evolutionary Requirements 53

迭代 1基础知识 123

Iteration 1Basics 123

DesignIteratively 的要求 195

Requirements to DesignIteratively 195

有关迭代开发和敏捷项目管理的更多信息 673

More on Iterative Development and Agile Project Management 673

OO 分析

OO Analysis

看域建模和操作协定

See Domain Modeling and Operation Contracts

OO 设计

OO Design

看GRASP 和 GoF 设计模式

See GRASP and GoF Design Patterns

继续进行对象设计 213

On to Object Design 213

包装设计 613

Package Design 613

运营合同

Operation Contracts

运营合同 181

Operation Contracts 181

运营合同和用例实现 326

Operation Contracts and Use Case Realizations 326

更多 SSD 和合同 501

More SSDs and Contracts 501

模式

Patterns

看GRASP 和 GoF 设计模式

See GRASP and GoF Design Patterns

什么是模式？278 元

What are Patterns? 278

编程

Programming

将设计映射到 Code 369

Mapping Designs to Code 369

测试驱动开发和重构 385

Test-Driven Development and Refactoring 385

项目管理

Project Management

看敏捷实践和迭代开发

See Agile Practices and Iterative Development

有关迭代开发和敏捷项目管理的更多信息 673

More on Iterative Development and Agile Project Management 673

要求

Requirements

看使用案例

See Use Cases

进化要求 53

Evolutionary Requirements 53

其他要求 101

Other Requirements 101

DesignIteratively 的要求 195

Requirements to DesignIteratively 195

UML 活动图和建模 477

UML Activity Diagrams and Modeling 477

UML 状态机图和建模 485

UML State Machine Diagrams and Modeling 485

系统序列 dgms

System Sequence Dgms

系统序列图 173

System Sequence Diagrams 173

SSD、系统操作、交互图和用例实现 324

SSDs, System Operations, Interaction Diagrams, and Use Case Realizations 324

更多 SSD 和合同 501

More SSDs and Contracts 501

测试

Testing

测试驱动开发和重构 385

Test-Driven Development and Refactoring 385

UML

UML

什么是 UML？11

What is the UML? 11

应用 UML：用例图 89

Applying UML: Use Case Diagrams 89

域模型 131

Domain Models 131

应用 UML：序列图 177

Applying UML: Sequence Diagrams 177

应用 UML：包图 201

Applying UML: Package Diagrams 201

UML 交互图 221

UML Interaction Diagrams 221

UML 类图 249

UML Class Diagrams 249

UML 活动图和建模 477

UML Activity Diagrams and Modeling 477

UML 状态机图和建模 485

UML State Machine Diagrams and Modeling 485

用例图 499

Use Case Diagrams 499

UML 部署和组件图 621

UML Deployment and Component Diagrams 621

统一流程

Unified Process

什么是 Agile UP？31

What is an Agile UP? 31

还有其他关键的 UP 实践吗？33

Are There Other Critical UP Practices? 33

有关迭代开发和敏捷项目管理的更多信息 673

More on Iterative Development and Agile Project Management 673

使用案例

Use Cases

使用案例 61

Use Cases 61

SSD 和用例之间有什么关系？177 元

What is the Relationship Between SSDs and Use Cases? 177

什么是用例实现？322 元

What is a Use Case Realization? 322

相关用例 493

Relating Use Cases 493

如何使用用例和场景规划迭代？676 元

How to Plan Iterations with Use Cases and Scenarios? 676

前言

Foreword

编程很有趣，但开发高质量的软件却很困难。在美好的想法、需求或 “愿景” 和有效的软件产品之间，除了编程之外，还有更多的东西。分析和设计，定义如何解决问题，编程什么，以易于沟通、审查、实施和发展的方式捕获此设计，这就是本书的核心。这就是您将学到的。

Programming is fun, but developing quality software is hard. In between the nice ideas, the requirements or the "vision," and a working software product, there is much more than programming. Analysis and design, defining how to solve the problem, what to program, capturing this design in ways that are easy to communicate, to review, to implement, and to evolve is what lies at the core of this book. This is what you will learn.

统一建模语言 （UML） 已成为软件设计蓝图的普遍接受的语言。UML 是本书中用于传达设计思想的视觉语言，它强调开发人员如何真正应用经常使用的 UML 元素，而不是晦涩难懂的语言功能。

The Unified Modeling Language (UML) has become the universally-accepted language for software design blueprints. UML is the visual language used to convey design ideas throughout this book, which emphasizes how developers really apply frequently used UML elements, rather than obscure features of the language.

模式在构建复杂系统方面的重要性在其他学科中早已得到认可。软件设计模式使我们能够描述设计片段，并重用设计理念，帮助开发人员利用他人的专业知识。模式为抽象的启发式方法、规则和面向对象技术的最佳实践提供了名称和形式。没有一个理性的工程师愿意从零开始，这本书提供了一个易于使用的设计模式调色板。

The importance of patterns in crafting complex systems has long been recognized in other disciplines. Software design patterns are what allow us to describe design fragments, and reuse design ideas, helping developers leverage the expertise of others. Patterns give a name and form to abstract heuristics, rules and best practices of object-oriented techniques. No reasonable engineer wants to start from a blank slate, and this book offers a palette of readily usable design patterns.

但是，如果不在软件工程过程的上下文中呈现软件设计，则看起来有点枯燥和神秘。在这个话题上，我很高兴 Craig Larman 在他的新版本中选择接受并引入统一流程，展示了如何以相对简单和低仪式的方式应用它。通过在迭代、风险驱动、以架构为中心的过程中呈现案例研究，Craig 的建议具有现实的背景;他揭示了软件开发中真正发生的事情的动态，并展示了起作用的外部力量。设计活动与其他任务相关联，它们不再表现为纯粹的系统性转换或创造性直觉的脑力活动。Craig 和我都深信迭代开发的好处，您将在整篇文章中看到大量说明。

But software design looks a bit dry and mysterious when not presented in the context of a software engineering process. And on this topic, I am delighted that for his new edition, Craig Larman has chosen to embrace and introduce the Unified Process, showing how it can be applied in a relatively simple and low-ceremony way. By presenting the case study in an iterative, risk-driven, architecture-centric process, Craig's advice has realistic context; he exposes the dynamics of what really happens in software development, and shows the external forces at play. The design activities are connected to other tasks, and they no longer appear as a purely cerebral activity of systematic transformations or creative intuition. And Craig and I are convinced of the benefits of iterative development, which you will see abundantly illustrated throughout.

所以对我来说，这本书的成分组合是正确的。您将从一位伟大的老师、一位才华横溢的方法论者和一位向世界各地成千上万的人传授面向对象的分析和设计 （OO 大师） 那里学习一种系统的方法。Craig 在 Unified Process 的上下文中描述了该方法。他逐渐提出了更复杂的设计模式，这将使本书在您面临现实世界的设计挑战时非常方便。他使用了最广泛接受的符号。

So for me, this book has the right mix of ingredients. You will learn a systematic method to do Object-Oriented Analysis and Design (OOA/D) from a great teacher, a brilliant methodologist, and an "OO guru" who has taught it to thousands around the world. Craig describes the method in the context of the Unified Process. He gradually presents more sophisticated design patternsthis will make the book very handy when you are faced with real-world design challenges. And he uses the most widely accepted notation.

我很荣幸有机会直接与这本重要著作的作者合作。我喜欢阅读第一版，当他让我审阅他的新版草稿时，我很高兴。我们见过几次面，交换了很多电子邮件。我从 Craig 那里学到了很多东西，甚至了解了我们自己在统一流程上的流程工作，以及如何改进它并在各种组织环境中定位它。我确信，即使您已经熟悉 OOA/D，您也会在阅读本书中学到很多东西。而且，像我一样，你会发现自己回到它，刷新你的记忆，或者从 Craig 的解释和经验中获得进一步的见解。

I'm honored to have had the opportunity to work directly with the author of this major book. I enjoyed reading the first edition, and was delighted when he asked me to review the draft of his new edition. We met several times and exchanged many e-mails. I have learned much from Craig, even about our own process work on the Unified Process and how to improve it and position it in various organizational contexts. I am certain that you will learn a lot, too, in reading this book, even if you are already familiar with OOA/D. And, like me, you will find yourself going back to it, to refresh your memory, or to gain further insights from Craig's explanations and experience.

祝您阅读愉快！

Happy reading!

不列颠哥伦比亚



大学软件工程 Philippe Kruchten

教授，

不列颠哥伦比亚省温哥华 RUP

Rational Software

的 Rational 研究员和流程开发总监

Philippe Kruchten

Professor of Software Engineering, University of British Columbia



formerly,

Rational Fellow and Director of Process Development for the RUP

Rational Software

Vancouver, British Columbia

前言

Preface

感谢您阅读本书！如果我能回答一个问题，或者咨询或指导一个团队（在 OOA/D、UML、建模、迭代和敏捷方法方面），请通过 www.craiglarman.com 与我联系。

Thank you for reading this book! If I can answer a question, or for consulting or coaching a team (in OOA/D, UML, modeling, iterative and agile methods) please contact me at www.craiglarman.com.

这是对面向对象的分析和设计 （OOA/D） 以及迭代开发的相关方面的实用介绍。我很感激以前的版本在世界范围内非常受欢迎。衷心感谢所有读者！

This is a practical introduction to object-oriented analysis and design (OOA/D), and to related aspects of iterative development. I am grateful that the previous editions were extremely popular worldwide. I sincerely thank all the readers!

以下是这本书将如何使您受益。

Here is how the book will benefit you.

首先，对象技术的使用很普遍，因此掌握 OOA/D 对于您在软件世界中取得成功至关重要。

First, the use of object technology is widespread, so mastery of OOA/D is critical for you to succeed in the software world.

其次，如果你是 OOA/D 的新手，你会在如何进行方面遇到挑战，这是可以理解的;本书提出了一个定义明确的迭代路线图统一流程的敏捷方法，以便您可以逐步完成从需求到代码的流程。

Second, if you are new to OOA/D, you're understandably challenged about how to proceed; this book presents a well-defined iterative roadmapan agile approach to the Unified Processso that you can move in a step-by-step process from requirements to code.

第三，统一建模语言 （UML） 已成为建模的标准表示法，因此能够巧妙地应用它非常有用。

Third, the Unified Modeling Language (UML) has emerged as the standard notation for modeling, so it's useful to be able to apply it skillfully.

第四，设计模式传达了 OO 设计专家应用的 “最佳实践” 习语。您将学习应用设计模式，包括流行的“四人组”模式和 GRASP 模式。学习和应用 pattern 将加速您对分析和设计的掌握。

Fourth, design patterns communicate the "best practice" idioms OO design experts apply. You will learn to apply design patterns, including the popular "gang-of-four" patterns, and the GRASP patterns. Learning and applying patterns will accelerate your mastery of analysis and design.

第五，本书的结构和重点基于多年的教育经验和指导成千上万的 OOA/D 艺术。它通过提供一种精致、成熟且高效的方法来学习该主题来反映这种体验，因此您在阅读和学习方面的投资得到了优化。

Fifth, the structure and emphasis in this book are based on years of experience in education and mentoring thousands of people in the art of OOA/D. It reflects that experience by providing a refined, proven, and efficient approach to learning the subject, so your investment in reading and learning is optimized.

第六，它详尽地研究了两个案例研究，以真实地说明整个 OOA/D 过程，并深入探讨了问题的棘手细节。

Sixth, it exhaustively examines two case studiesto realistically illustrate the entire OOA/D process, and goes deeply into thorny details of the problem.

第七，它展示了如何将对象设计工件映射到 Java 中的代码。它还引入了测试驱动开发和重构。

Seventh, it shows how to map object design artifacts to code in Java. It also introduces test-driven development and refactor.

第八，它解释了如何设计分层架构并将 UI 层与领域和技术服务层相关联。

Eighth, it explains how to design a layered architecture and relate the UI layer to domain and technical services layers.

最后，它向您展示如何设计 OO 框架，并将其应用于在数据库中创建持久存储框架。

Finally, it shows you how to design an OO framework and applies this to the creation of a framework for persistent storage in a database.

教育工作者和 Web 资源

Educator and Web Resources

您可以在 www.craiglarman.com 上找到感兴趣的相关文章。

You may find related articles of interest at www.craiglarman.com.

全世界有数百甚至数千名教师使用这本书;它已被翻译成至少十种语言。在我的网站上有各种教育工作者资源，包括组织成 Microsoft PowerPoint 演示文稿的所有书籍图表、OOA/D PowerPoint 演示文稿示例等。如果您是教育工作者，请与我联系以获取资源。

Hundreds, if not thousands, of teachers use the book worldwide; it's been translated into at least ten languages. At my website there are a variety of educator resources, including all the book figures organized into Microsoft PowerPoint presentations, sample OOA/D PowerPoint presentations, and more. If you're an educator, please contact me for resources.

我正在使用这本书从现有教育工作者那里收集材料，以便与其他教育工作者分享。如果您有任何要分享的内容，请与我联系。

I am collecting material from existing educators using the book, to share with other educators. If you have anything to share, please contact me.

目标受众介绍！

Intended Audiencean Introduction!

本书介绍了 OOA/D、相关需求分析以及以 Unified Process 作为示例流程的迭代开发;它不是高级文本。它适用于以下受众：

This book is an introduction to OOA/D, related requirements analysis, and to iterative development with the Unified Process as a sample process; it is not meant as an advanced text. It is for the following audience:

• 具有一些 OO 编程经验，但对 OOA/D 不熟悉或相对较新的开发人员和学生。

• Developers and students with some experience in OO programming, but who are newor relatively newto OOA/D.

• 学习对象技术的计算机科学或软件工程课程的学生。

• Students in computer science or software engineering courses studying object technology.

• 那些对 OOA/D 有一定了解，想要学习 UML 表示法、应用模式或想要加深其分析和设计技能的人。

• Those with some familiarity in OOA/D who want to learn the UML notation, apply patterns, or who want to deepen their analysis and design skills.

先决条件

Prerequisites

要从本书中受益，必须满足一些先决条件：

Some prerequisites are assumedand necessaryto benefit from this book:

• 具备面向对象编程语言（如 Java、C#、C++ 或 Python）的知识和经验。

• Knowledge and experience in an object-oriented programming language such as Java, C#, C++, or Python.

• 了解基本的 OO 概念，例如类、实例、接口、多态性、封装和继承。

• Knowledge of fundamental OO concepts, such as class, instance, interface, polymorphism, encapsulation, and inheritance.

基本 OO 概念未定义。

Fundamental OO concepts are not defined.

Java 示例，但是......

Java Examples, But …

总的来说，由于 Java 被广泛熟悉，因此本书提供了 Java 代码示例。但是，所提出的想法适用于大多数（如果不是全部）面向对象的技术，包括 C#、Python 等。

In general, the book presents code examples in Java due to its widespread familiarity. However, the ideas presented are applicable to mostif not allobject-oriented technologies, including C#, Python, and so on.

书籍组织

Book Organization

本书组织的总体策略是，分析和设计主题的顺序类似于软件开发项目运行的顺序，贯穿“开始”阶段（统一过程术语），然后是三个迭代（参见图 P.1）。

The overall strategy in the organization of this book is that analysis and design topics are introduced in an order similar to that of a software development project running across an "inception" phase (a Unified Process term) followed by three iterations (see Figure P.1).

图 P.1.本书的组织遵循一个开发项目的组织。

[查看全尺寸图片]

关于作者

About the Author

Craig Larman 担任 Valtech 的首席科学家，Valtech 是一家国际咨询和技能转移公司，在欧洲、亚洲和北美设有分支机构。他还是畅销软件工程和迭代敏捷开发文本 Agile and Iterative Development： A Manager's Guide 的作者。他周游世界，从印第安纳州到印度，指导开发团队和经理。

Craig Larman serves as chief scientist for Valtech, an international consulting and skills transfer company with divisions in Europe, Asia, and North America. He is also author of the best-selling software engineering and iterative, agile development text Agile and Iterative Development: A Manager's Guide. He travels worldwide, from Indiana to India, coaching development teams and managers.

自 1980 年代中期以来，Craig 已帮助成千上万的开发人员应用 OOA/D、熟练地使用 UML 进行建模，并采用迭代开发实践。

Since the mid 1980s, Craig has helped thousands of developers to apply OOA/D, skillful modeling with the UML, and to adopt iterative development practices.

在作为流浪街头音乐家的失败职业生涯之后，他在 1970 年代构建了 APL、PL/I 和 CICS 系统。从 1980 年代初开始，在完全康复后，他对人工智能产生了兴趣（他自己的人工智能很少），并使用 Lisp 机器、Lisp、Prolog 和 Smalltalk 构建了知识系统。他还曾在使用 Java、.NET、C++ 和 Smalltalk 构建业务系统的组织中工作。他在自己的兼职乐队 Changing Requirements 中弹吉他很糟糕（以前叫 Requirements，但一些乐队成员改变了......

After a failed career as a wandering street musician, he built systems in APL, PL/I, and CICS in the 1970s. Starting in the early 1980safter a full recovery he became interested in artificial intelligence (having little of his own) and built knowledge systems with Lisp machines, Lisp, Prolog, and Smalltalk. He's also worked in organizations that build business systems in Java, .NET, C++, and Smalltalk. He plays bad lead guitar in his very part-time band, the Changing Requirements (it used to be called the Requirements, but some band members changed...).

他拥有加拿大温哥华美丽的西蒙弗雷泽大学的计算机科学学士和硕士学位。

He holds a B.S. and M.S. in computer science from beautiful Simon Fraser University in Vancouver, Canada.

联系

Contact

您可以通过 craig@craiglarman.com 和 www.craiglarman.com 联系 Craig。他欢迎读者和教育工作者提出问题，并欢迎演讲、指导和咨询咨询。

Craig can be reached at craig@craiglarman.com and www.craiglarman.com. He welcomes questions from readers and educators, and speaking, mentoring, and consulting enquiries.

对上一版本的增强

Enhancements to the Previous Edition

在保留与上一版本相同的核心的同时，此版本在许多方面进行了改进，包括：

While retaining the same core as the prior edition, this edition is refined in many ways, including:

• UML 2

• UML 2

• 第二个案例研究

• A second case study

• 有关迭代和进化开发与 OOA/D 相结合的更多提示

• More tips on iterative and evolutionary development combined with OOA/D

• 使用新的学习辅助工具和图形重写，以便于学习

• Rewritten with new learning aids and graphics for easier study

• 新的大学教育工作者教学资源

• New college-educator teaching resources

• 敏捷建模、测试驱动开发和重构

• Agile Modeling, Test-Driven Development, and refactoring

• 有关使用 UML 活动图进行流程建模的更多信息

• More on process modeling with UML activity diagrams

• 以轻松、敏捷的精神应用 UP，与其他迭代方法（如 XP 和 Scrum）相辅相成

• Guidance on applying the UP in a light, agile spirit, complementary with other iterative methods such as XP and Scrum

• 将 UML 应用于记录体系结构

• Applying the UML to documenting architectures

• 关于进化需求的新篇章

• A new chapter on evolutionary requirements

• 使用非常流行的 [Cockburn01]

• Refinement of the use case chapters, using the very popular approach of [Cockburn01]

确认

Acknowledgments

首先，感谢我在 Valtech 的朋友和同事，他们是世界级的对象开发人员和迭代开发专家，他们以某种方式为本书做出了贡献、支持或审阅了这本书，包括 Chris Tarr、Tim Snyder、Curtis Hite、Celso Gonzalez、Pascal Roques、Ken DeLong、Brett Schuchert、Ashley Johnson、Chris Jones、Thomas Liou、Darryl Gebert，以及我无法列举的许多人。

First, thanks to my friends and colleagues at Valtech, world-class object developers and iterative development experts, who in some way contributed to, supported, or reviewed the book, including Chris Tarr, Tim Snyder, Curtis Hite, Celso Gonzalez, Pascal Roques, Ken DeLong, Brett Schuchert, Ashley Johnson, Chris Jones, Thomas Liou, Darryl Gebert, and many more than I can name.

感谢 Philippe Kruchten 撰写前言、审阅和以多种方式提供帮助。

To Philippe Kruchten for writing the foreword, reviewing, and helping in many ways.

感谢 Martin Fowler 和 Alistair Cockburn 对流程和设计、报价和评论的许多有见地的讨论。

To Martin Fowler and Alistair Cockburn for many insightful discussions on process and design, quotes, and reviews.

感谢 Oystein Haugen、Cris Kobryn、Jim Rumbaugh 和 Bran Selic 审阅 UML 2 材料。

To Oystein Haugen, Cris Kobryn, Jim Rumbaugh, and Bran Selic for reviewing the UML 2 material.

感谢 John Vlissides 和 Cris Kobryn 的善意引用。

To John Vlissides and Cris Kobryn for the kind quotes.

感谢 Chelsea Systems 和 John Gray 帮助解决受其 Java 技术 ChelseaStore POS 系统启发的一些需求。

To Chelsea Systems and John Gray for help with some requirements inspired by their Java technology ChelseaStore POS system.

感谢 Pete Coad 和 Dave Astels 的意见。

To Pete Coad and Dave Astels for their input.

非常感谢其他审稿人，包括 Steve Adolph、Bruce Anderson、Len Bass、Gary K. Evans、Al Goerner、Luke Hohmann、Eric Lefebvre、David Nunn 和 Robert J. White。

Many thanks to the other reviewers, including Steve Adolph, Bruce Anderson, Len Bass, Gary K. Evans, Al Goerner, Luke Hohmann, Eric Lefebvre, David Nunn, and Robert J. White.

感谢 Prentice-Hall 的 Paul Becker 相信第一版将是一个有价值的项目，并感谢 Paul Petralia 指导后来的版本。

Thanks to Paul Becker at Prentice-Hall for believing the first edition would be a worthwhile project, and to Paul Petralia for shepherding the later ones.

最后，特别感谢 Graham Glass 打开了一扇门。

Finally, a special thanks to Graham Glass for opening a door.

排版约定

Typographical Conventions

这是一个新词。这是句子中的 Class 或 method 名称。这是作者参考 [Bob67]。

This is a new term in a sentence. This is a Class or method name in a sentence. This is an author reference [Bob67].

制作说明

Production Notes

该手稿是使用 Adobe FrameMaker 创建的。所有图纸均使用 Microsoft Visio 完成。正文字体为 New Century Schoolbook。最终的打印图像是使用 Adobe Acrobat Distiller 从 Adobe Universal 驱动程序生成的 PostScript 生成为 PDF。使用 ClearBoard 清理了 UML 墙壁草图照片，用于白板照片。

The manuscript was created with Adobe FrameMaker. All drawings were done with Microsoft Visio. The body font is New Century Schoolbook. The final print images were generated as PDF using Adobe Acrobat Distiller, from PostScript generated by the Adobe Universal driver. The UML wall sketch photos were cleaned up with ClearBoard for whiteboard photos.

第 1 部分：简介

Part 1: Introduction

第 1 章. 面向对象的分析和设计

Chapter 1.  Object-Oriented Analysis and Design

第 2 章. 迭代、进化和敏捷

Chapter 2.  Iterative, Evolutionary, and Agile

第 3 章. 案例研究

Chapter 3.  Case Studies

第 1 章.面向对象的分析和设计

Chapter 1. Object-Oriented Analysis and Design

Le temps est un grand professeur， mais malheureusement il tue tous ses élèves （时间是一位伟大的老师，但不幸的是，它杀死了所有的学生。

赫克托·柏辽兹

Le temps est un grand professeur, mais malheureusement il tue tous ses élèves (Time is a great teacher, but unfortunately it kills all its pupils.)

Hector Berlioz

1.1. 您将学到什么？它有用吗？

1.1. What Will You Learn? Is it Useful?

拥有一个好的对象设计意味着什么？本书是帮助开发人员和学生学习面向对象分析和设计 （OOA/D） 核心技能的工具。这些技能对于使用 OO 技术和语言（如 Java 或 C#）创建设计良好、健壮且可维护的软件至关重要。

What does it mean to have a good object design? This book is a tool to help developers and students learn core skills in object-oriented analysis and design (OOA/D). These skills are essential for the creation of well-designed, robust, and maintainable software using OO technologies and languages such as Java or C#.

谚语“拥有锤子并不能使人成为建筑师”这句谚语在对象技术方面尤其适用。了解面向对象的语言（比如 Java）是创建对象系统的必要但不够的第一步。知道如何 “在对象中思考 ”是至关重要的！

The proverb "owning a hammer doesn't make one an architect" is especially true with respect to object technology. Knowing an object-oriented language (such as Java) is a necessary but insufficient first step to create object systems. Knowing how to "think in objects" is critical!

这是在应用统一建模语言 （UML） 和模式时对 OOA/D 的介绍。对于迭代开发，使用统一流程的敏捷方法作为示例迭代流程。它并不意味着高级文本;它强调对基础知识的掌握，例如如何为对象分配职责、常用的 UML 表示法和常见的设计模式。同时，主要是在后面的章节中，材料会发展到一些中级主题，例如框架设计和架构分析。

This is an introduction to OOA/D while applying the Unified Modeling Language (UML) and patterns. And, to iterative development, using an agile approach to the Unified Process as an example iterative process. It is not meant as an advanced text; it emphasizes mastery of the fundamentals, such as how to assign responsibilities to objects, frequently used UML notation, and common design patterns. At the same time, mostly in later chapters, the material progresses to some intermediate-level topics, such as framework design and architectural analysis.

UML 与对象思维

UML vs. Thinking in Objects

这本书不仅仅是关于 UML 的。UML 是一种标准的图表符号。通用表示法很有用，但还有更重要的 OO 内容需要学习，尤其是如何在对象中思考。UML 不是 OOA/D 或方法，它只是图表符号。学习 UML 和 UML CASE 工具是没有用的，但不知道如何创建出色的 OO 设计，或者评估和改进现有的 OO 设计。这是困难而重要的技能。因此，本书是对对象设计的介绍。

The book is not just about UML. The UML is a standard diagramming notation. Common notation is useful, but there are more important OO things to learn especially, how to think in objects. The UML is not OOA/D or a method, it is just diagramming notation. It's useless to learn UML and perhaps a UML CASE tool, but not really know how to create an excellent OO design, or evaluate and improve an existing one. This is the hard and important skill. Consequently, this book is an introduction to object design.

然而，我们需要一种用于 OOA/D 和 “软件蓝图” 的语言，它既可以作为一种思考工具，也作为一种交流形式。因此，本书探讨了如何将 UML 应用于执行 OOA/D 的服务，并介绍了常用的 UML。

Yet, we need a language for OOA/D and "software blueprints," both as a tool of thought and as a form of communication. Therefore, this book explores how to apply the UML in the service of doing OOA/D, and covers frequently used UML.

OOD：原则和模式

OOD: Principles and Patterns

应该如何为对象类分配责任？对象应该如何协作？什么类应该做什么？这些都是系统设计中的关键问题，这本书讲授了经典的 OO 设计比喻：责任驱动设计。此外，设计问题的某些久经考验的解决方案可以（并且已经）表示为最佳实践原则、启发式或称为问题解决公式的模式，这些公式将示例性设计原则编纂成文。这本书通过教授如何应用模式或原则，支持更快地学习和熟练使用这些基本的对象设计习惯用法。

How should responsibilities be allocated to classes of objects? How should objects collaborate? What classes should do what? These are critical questions in the design of a system, and this book teaches the classic OO design metaphor: responsibility-driven design. Also, certain tried-and-true solutions to design problems can be (and have been) expressed as best-practice principles, heuristics, or patternsnamed problem-solution formulas that codify exemplary design principles. This book, by teaching how to apply patterns or principles, supports quicker learning and skillful use of these fundamental object design idioms.

案例研究

Case Studies

OOA/D 的介绍在本书中遵循的一些正在进行的案例研究中进行了说明，深入到分析和设计中，以便考虑并解决实际问题中必须考虑和解决的一些血腥细节。

This introduction to OOA/D is illustrated in some ongoing case studies that are followed throughout the book, going deep enough into the analysis and design so that some of the gory details of what must be considered and solved in a realistic problem are considered, and solved.

使用案例

Use Cases

OOD（和所有软件设计）与需求分析的先决条件活动密切相关，这通常包括编写用例。因此，案例研究从对这些主题的介绍开始，即使它们不是专门面向对象的。

OOD (and all software design) is strongly related to the prerequisite activity of requirements analysis, which often includes writing use cases. Therefore, the case study begins with an introduction to these topics, even though they are not specifically object-oriented.

迭代开发、敏捷建模和敏捷 UP

Iterative Development, Agile Modeling, and an Agile UP

考虑到从需求到实施的许多可能活动，开发人员或团队应该如何进行？需求分析和 OOA/D 需要在一些开发过程的上下文中提出和实践。在这种情况下，使用众所周知的统一流程 （UP） 的敏捷 （轻量级、灵活） 方法作为示例迭代开发过程，其中介绍了这些主题。但是，所涵盖的分析和设计主题在许多方法中都是通用的，在敏捷 UP 的上下文中学习它们并不会使它们对其他方法的适用性无效，例如 Scrum、功能驱动开发、精益开发、Crystal 方法等。

Given many possible activities from requirements through to implementation, how should a developer or team proceed? Requirements analysis and OOA/D needs to be presented and practiced in the context of some development process. In this case, an agile (light, flexible) approach to the well-known Unified Process (UP) is used as the sample iterative development process within which these topics are introduced. However, the analysis and design topics that are covered are common to many approaches, and learning them in the context of an agile UP does not invalidate their applicability to other methods, such as Scrum, Feature-Driven Development, Lean Development, Crystal Methods, and so on.

许多其他技能也很重要！

Many Other Skills Are Important!

这不是软件的完备之书;它主要是对 OOA/D、UML 和迭代开发的介绍，同时涉及相关主题。构建软件涉及无数其他技能和步骤;例如，可用性工程、用户界面设计和数据库设计是成功的关键。

This isn't the Compleate Booke of Software; it's primarily an introduction to OOA/D, UML, and iterative development, while touching on related subjects. Building software involves myriad other skills and steps; for example, usability engineering, user interface design, and database design are critical to success.

1.2. 最重要的学习目标是什么？

1.2. The Most Important Learning Goal?

在入门 OOA/D 中有许多可能的活动和工件，以及丰富的原则和指南。假设我们必须从这里讨论的所有主题中选择一项实践技能，即“荒岛”技能。那会是什么？

There are many possible activities and artifacts in introductory OOA/D, and a wealth of principles and guidelines. Suppose we must choose a single practical skill from all the topics discussed herea "desert island" skill. What would it be?

为什么？因为它是一项必须在绘制 UML 图或编程时执行的活动，并且它强烈影响软件组件的健壮性、可维护性和可重用性。

Why? Because it is one activity that must be performedeither while drawing a UML diagram or programmingand it strongly influences the robustness, maintainability, and reusability of software components.

当然，OOA/D 中还有其他重要的技能，但本介绍强调了责任分配，因为它往往是一项具有挑战性的技能（具有许多“自由度”或替代方案），但至关重要。在实际项目中，开发人员可能没有机会执行任何其他建模活动，即“匆忙编写代码”开发过程。然而，即使在这种情况下，分配责任也是不可避免的。

Of course, there are other important skills in OOA/D, but responsibility assignment is emphasized in this introduction because it tends to be a challenging skill to master (with many "degrees of freedom" or alternatives), and yet is vitally important. On a real project, a developer might not have the opportunity to perform any other modeling activitiesthe "rush to code" development process. Yet even in this situation, assigning responsibilities is inevitable.

因此，本书中的设计步骤强调责任分配原则。

Consequently, the design steps in this book emphasize principles of responsibility assignment.

1.3. 什么是分析与设计？

1.3. What is Analysis and Design?

分析强调对问题和需求的调查，而不是解决方案。例如，如果需要一个新的在线交易系统，它将如何使用它？它的功能是什么？

Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new online trading system is desired, how will it be used? What are its functions?

“分析” 是一个广义的术语，最有资格的术语，如需求分析（对需求的调查）或面向对象的分析（对领域对象的调查）。

"Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the requirements) or object-oriented analysis (an investigation of the domain objects).

设计强调满足需求的概念解决方案（在软件和硬件中），而不是其实现。例如，数据库架构和软件对象的描述。设计理念通常排除了对目标消费者来说显而易见的低级或“明显”细节。最终，设计是可以实现的，而实现（如代码）表达了真实而完整的实现设计。

Design emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. Design ideas often exclude low-level or "obvious" detailsobvious to the intended consumers. Ultimately, designs can be implemented, and the implementation (such as code) expresses the true and complete realized design.

与分析一样，该术语是最合格的，如面向对象设计或数据库设计。

As with analysis, the term is best qualified, as in object-oriented design or database design.

有用的分析和设计已经总结在短语 do the right thing （analysis） 和 do the thing right （design） 中。

Useful analysis and design have been summarized in the phrase do the right thing (analysis), and do the thing right (design).

1.4. 什么是面向对象的分析和设计？

1.4. What is Object-Oriented Analysis and Design?

在面向对象的分析过程中，强调在问题域中查找和描述对象或概念。例如，在飞行信息系统的情况下，一些概念包括 Plane、Flight 和 Pilot。

During object-oriented analysis there is an emphasis on finding and describing the objectsor conceptsin the problem domain. For example, in the case of the flight information system, some of the concepts include Plane, Flight, and Pilot.

在面向对象设计（或简称对象设计）期间，强调定义软件对象以及它们如何协作以满足需求。例如，Plane 软件对象可能具有 tailNumber 属性和 getFlightHistory 方法（参见图 1.2）。

During object-oriented design (or simply, object design) there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, a Plane software object may have a tailNumber attribute and a getFlightHistory method (see Figure 1.2).

图 1.2.面向对象强调对象的表示。

[查看全尺寸图片]

最后，在实现或面向对象编程期间，将实现设计对象，例如 Java 中的 Plane 类。

Finally, during implementation or object-oriented programming, design objects are implemented, such as a Plane class in Java.

1.5. 一个简短的例子 1.5. A Short Example

在深入探讨迭代开发、需求分析、UML 和 OOA/D 的细节之前，本节使用一个简单的示例“骰子游戏”，其中软件模拟玩家掷两个骰子，简要介绍了几个关键步骤和图表。如果总点数为 7，则他们获胜;否则，他们就输了。

Before diving into the details of iterative development, requirements analysis, UML, and OOA/D, this section presents a bird's-eye view of a few key steps and diagrams, using a simple examplea "dice game" in which software simulates a player rolling two dice. If the total is seven, they win; otherwise, they lose.

定义用例

Define Use Cases

需求分析可能包括人们如何使用应用程序的故事或场景;这些可以编写为用例。

Requirements analysis may include stories or scenarios of how people use the application; these can be written as use cases.

用例不是面向对象的工件，它们只是编写的故事。但是，它们是需求分析中的常用工具。例如，以下是 Play a Dice Game 用例的简要版本：

Use cases are not an object-oriented artifactthey are simply written stories. However, they are a popular tool in requirements analysis. For example, here is a brief version of the Play a Dice Game use case:

玩骰子游戏：玩家要求掷骰子。系统显示结果：如果骰子面值总点数为 7，则玩家获胜;否则，玩家输。

Play a Dice Game: Player requests to roll the dice. System presents results: If the dice face value totals seven, player wins; otherwise, player loses.

定义域模型

Define a Domain Model

面向对象的分析涉及从对象的角度创建域的描述。其中确定了被认为值得注意的概念、属性和关联。

Object-oriented analysis is concerned with creating a description of the domain from the perspective of objects. There is an identification of the concepts, attributes, and associations that are considered noteworthy.

结果可以用一个域模型来表示，该模型显示了值得注意的域概念或对象。

The result can be expressed in a domain model that shows the noteworthy domain concepts or objects.

例如，部分域模型如图 1.3 所示。

For example, a partial domain model is shown in Figure 1.3.

此模型说明了值得注意的概念 Player、Die 和 DiceGame 及其关联和属性。

This model illustrates the noteworthy concepts Player, Die, and DiceGame, with their associations and attributes.

请注意，域模型不是软件对象的描述;它是现实世界领域的概念或心智模型的可视化。因此，它也被称为概念对象模型。

Note that a domain model is not a description of software objects; it is a visualization of the concepts or mental models of a real-world domain. Thus, it has also been called a conceptual object model.

分配对象职责并绘制交互图

Assign Object Responsibilities and Draw Interaction Diagrams

面向对象设计关注定义软件对象、它们的职责和协作。说明这些协作的一种常见表示法是序列图（一种 UML 交互图）。它显示了软件对象之间的消息流，从而显示了方法的调用。

Object-oriented design is concerned with defining software objectstheir responsibilities and collaborations. A common notation to illustrate these collaborations is the sequence diagram (a kind of UML interaction diagram). It shows the flow of messages between software objects, and thus the invocation of methods.

例如，图 1.4 中的序列图通过向 DiceGame 和 Die 类的实例发送消息来说明一个 OO 软件设计。请注意，这说明了应用 UML 的一种常见实际方式：在白板上绘制草图。

For example, the sequence diagram in Figure 1.4 illustrates an OO software design, by sending messages to instances of the DiceGame and Die classes. Note this illustrates a common real-world way the UML is applied: by sketching on a whiteboard.

请注意，尽管在现实世界中是玩家掷骰子，但在软件设计中，DiceGame 对象会“掷”骰子（即，向 Die 对象发送消息）。软件对象设计和程序确实从现实世界的领域中汲取了一些灵感，但它们不是现实世界的直接模型或模拟。

Notice that although in the real world a player rolls the dice, in the software design the DiceGame object "rolls" the dice (that is, sends messages to Die objects). Software object designs and programs do take some inspiration from real-world domains, but they are not direct models or simulations of the real world.

定义 Design 类图

Define Design Class Diagrams

除了交互图中显示的协作对象的动态视图外，类定义的静态视图还与设计类图一起有用地显示。这说明了类的属性和方法。

In addition to a dynamic view of collaborating objects shown in interaction diagrams, a static view of the class definitions is usefully shown with a design class diagram. This illustrates the attributes and methods of the classes.

例如，在骰子游戏中，检查序列图会得到图 1.5 所示的部分设计类图。由于播放消息是发送到 DiceGame 对象，因此 DiceGame 类需要一个 play 方法，而类 Die 需要一个 roll 和 getFaceValue 方法。

For example, in the dice game, an inspection of the sequence diagram leads to the partial design class diagram shown in Figure 1.5. Since a play message is sent to a DiceGame object, the DiceGame class requires a play method, while class Die requires a roll and getFaceValue method.

与显示实际类的域模型相反，此图显示了软件类。

In contrast to the domain model showing real-world classes, this diagram shows software classes.

请注意，尽管此设计类图与域模型不同，但某些类名和内容相似。通过这种方式，OO 设计和语言可以支持软件组件和我们的领域心智模型之间的较小表示差距。这提高了理解力。

Notice that although this design class diagram is not the same as the domain model, some class names and content are similar. In this way, OO designs and languages can support a lower representational gap between the software components and our mental models of a domain. That improves comprehension.

总结

Summary

骰子游戏是一个简单的问题，主要集中在分析和设计中的几个步骤和工件上。为了使介绍简单，并未解释所有图示的 UML 表示法。后续章节将更详细地探讨分析和设计以及这些工件。

The dice game is a simple problem, presented to focus on a few steps and artifacts in analysis and design. To keep the introduction simple, not all the illustrated UML notation was explained. Future chapters explore analysis and design and these artifacts in closer detail.

1.6. 什么是 UML？

1.6. What is the UML?

引用：

To quote:

统一建模语言是一种可视化语言，用于指定、构建和记录系统的工件 [OMG03a]。

The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems [OMG03a].

定义中的“视觉”一词是一个关键点UML 是事实上的标准图表符号，用于绘制或呈现与软件（主要是 OO 软件）相关的图片（带有一些文本）。

The word visual in the definition is a key pointthe UML is the de facto standard diagramming notation for drawing or presenting pictures (with some text) related to softwareprimarily OO software.

这本书并未涵盖 UML 的所有细微方面，UML 是一大堆符号。它侧重于常用的图表、其中最常用的功能，以及在未来的 UML 版本中不太可能改变的核心表示法。

This book doesn't cover all minute aspects of the UML, a large body of notation. It focuses on frequently used diagrams, the most commonly used features within those, and core notation that is unlikely to change in future UML versions.

UML 定义了各种 UML 配置文件，这些配置文件专门用于公共主题领域的表示法子集，例如，绘制 Enterprise JavaBeans（使用 UML EJB 配置文件）。

The UML defines various UML profiles that specialize subsets of the notation for common subject areas, such as diagramming Enterprise JavaBeans (with the UML EJB profile).

在更深的层次上，模型驱动架构 （MDA） CASE 工具供应商主要感兴趣的是 UML 表示法的基础是描述建模元素语义的 UML 元模型。这不是开发人员需要学习的东西。

At a deeper levelprimarily of interest to Model Driven Architecture (MDA) CASE tool vendorsunderlying the UML notation is the UML meta-model that describes the semantics of the modeling elements. It isn't something a developer needs to learn.

应用 UML 的三种方法

Three Ways to Apply UML

在 [Fowler03] 中，介绍了人们应用 UML 的三种方式：

In [Fowler03] three ways people apply UML are introduced:

• 作为草图的 UML非正式和不完整的图表（通常在白板上手绘）旨在探索问题或解决方案空间的困难部分，利用视觉语言的力量。

• UML as sketch Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space, exploiting the power of visual languages.

• UML 作为蓝图相对详细的设计图，用于 1） 逆向工程以可视化和更好地理解 UML 图中的现有代码，或 2） 代码生成（正向工程）。

• UML as blueprint Relatively detailed design diagrams used either for 1) reverse engineering to visualize and better understanding existing code in UML diagrams, or for 2) code generation (forward engineering).

• UML 和“银弹”思维 1986 年有一篇著名的论文，题为“没有银弹”，由 Frederick Brooks 博士撰写，也发表在他的经典著作 Mythical Man-Month（20周年纪念版）中。推荐阅读！一个关键的点是，认为软件中存在某种特殊的工具或技术会在生产力、减少缺陷、可靠性或简单性方面产生巨大的数量级差异，这是一个根本性的错误（到目前为止，无休止地重复）。工具并不能弥补设计的无知。 然而，您通常会听到来自工具供应商的说法，即绘制 UML 图会让事情变得更好;或者，基于 UML 的模型驱动架构 （MDA） 工具将成为突破性的灵丹妙药。 现实检查时间。UML 只是一个标准的图表符号框、线条等。使用通用符号进行可视化建模可能是一个很大的帮助，但它几乎不如知道如何设计和思考对象重要。这种设计知识是一项非常不同且更重要的技能，不是通过学习 UML 表示法或使用 CASE 或 MDA 工具来掌握的。一个没有好的 OO 设计和编程技能的人画 UML 只是画了糟糕的设计。我建议阅读文章 UML Fever 之死 [Bell04]（由 UML 创建者 Grady Booch 认可）以了解有关此主题的更多信息，以及 UML 是什么和不是什么 [Larman04]。 因此，本书介绍了 OOA/D 以及应用 UML 来支持熟练的 OO 设计。

  
  
  

  • 如果进行逆向工程，则 UML 工具会读取源或二进制文件，并生成（通常）UML 包、类和序列图。这些 “蓝图” 可以帮助读者理解大局元素、结构和协作。

  • 在编程之前，一些详细的图表可以为代码生成（例如，在 Java 中）提供指导，可以手动或使用工具自动生成。通常，这些图表用于某些代码，而其他代码则由开发人员在编码时填写（可能还应用 UML 草图）。

• UML and "Silver Bullet" Thinking There is a well-known paper from 1986 titled "No Silver Bullet" by Dr. Frederick Brooks, also published in his classic book Mythical Man-Month (20th anniversary edition). Recommended reading! An essential point is that it's a fundamental mistake (so far, endlessly repeated) to believe there is some special tool or technique in software that will make a dramatic order-of-magnitude difference in productivity, defect reduction, reliability, or simplicity. And tools don't compensate for design ignorance. Yet, you will hear claimsusually from tool vendorsthat drawing UML diagrams will make things much better; or, that Model Driven Architecture (MDA) tools based on UML will be the breakthrough silver bullet. Reality-check time. The UML is simply a standard diagramming notationboxes, lines, etc. Visual modeling with a common notation can be a great aid, but it is hardly as important as knowing how to design and think in objects. Such design knowledge is a very different and more important skill, and is not mastered by learning UML notation or using a CASE or MDA tool. A person not having good OO design and programming skills who draws UML is just drawing bad designs. I suggest the article Death by UML Fever [Bell04] (endorsed by the UML creator Grady Booch) for more on this subject, and also What UML Is and Isn't [Larman04]. Therefore, this book is an introduction to OOA/D and applying the UML to support skillful OO design.

  
  
  

  • If reverse engineering, a UML tool reads the source or binaries and generates (typically) UML package, class, and sequence diagrams. These "blueprints" can help the reader understand the big-picture elements, structure, and collaborations.

  • Before programming, some detailed diagrams can provide guidance for code generation (e.g., in Java), either manually or automatically with a tool. It's common that the diagrams are used for some code, and other code is filled in by a developer while coding (perhaps also applying UML sketching).

• UML 作为编程语言UML 中软件系统的完整可执行规范。可执行代码将自动生成，但开发人员通常不会看到或修改这些代码;一个只能在 UML “编程语言” 中工作。UML 的这种使用需要一种实用的方法来绘制所有行为或逻辑（可能使用交互或状态图），并且在理论、工具健壮性和可用性方面仍处于开发阶段。

• UML as programming language Complete executable specification of a software system in UML. Executable code will be automatically generated, but is not normally seen or modified by developers; one works only in the UML "programming language." This use of UML requires a practical way to diagram all behavior or logic (probably using interaction or state diagrams), and is still under development in terms of theory, tool robustness and usability.

敏捷建模强调 UML 作为草图;这是应用 UML 的常用方法，通常具有很高的时间投资回报（通常很短）。UML 工具可能很有用，但我鼓励人们也考虑使用敏捷建模方法来应用 UML。

Agile modeling emphasizes UML as sketch; this is a common way to apply the UML, often with a high return on the investment of time (which is typically short). UML tools can be useful, but I encourage people to also consider an agile modeling approach to applying UML.

应用 UML 的三个角度

Three Perspectives to Apply UML

UML 描述原始图类型，例如类图和序列图。它不会将建模视角叠加在这些上面。例如，相同的 UML 类图表示法可用于绘制现实世界中的概念或 Java 中的软件类的图片。

The UML describes raw diagram types, such as class diagrams and sequence diagrams. It does not superimpose a modeling perspective on these. For example, the same UML class diagram notation can be used to draw pictures of concepts in the real world or software classes in Java.

Syntropy 面向对象方法 [CD94] 强调了这一见解。也就是说，相同的符号可以用于三种透视图和类型的模型（图 1.6）：

This insight was emphasized in the Syntropy object-oriented method [CD94]. That is, the same notation may be used for three perspectives and types of models (Figure 1.6):

图 1.6.UML 的不同视角。

[查看全尺寸图片]

我们已经在图 1.3 和图 1.5 中看到了这样一个例子，其中使用相同的 UML 类图表示法来可视化域模型和设计模型。

We've already seen an example of this in Figure 1.3 and Figure 1.5, where the same UML class diagram notation is used to visualize a domain model and a design model.

在实践中，规范视角（推迟目标技术，例如 Java 与 .NET）很少用于设计;大多数面向软件的 UML 图都假定实现视角。

In practice, the specification perspective (deferring the target technology, such as Java versus .NET) is seldom used for design; most software-oriented UML diagramming assumes an implementation perspective.

不同角度中“类”的含义

在原始 UML 中，图 1.6 所示的矩形框称为类，但这个术语包含各种现象物理事物、抽象概念、软件事物、事件等。^[1]

In the raw UML, the rectangular boxes shown in Figure 1.6 are called classes, but this term encompasses a variety of phenomenaphysical things, abstract concepts, software things, events, and so forth.^[1]

^[1] UML 类是通用 UML 模型元素分类器的一种特殊情况，具有结构特征和/或行为，包括类、参与者、接口和用例。

^[1] A UML class is a special case of the general UML model element classifiersomething with structural features and/or behavior, including classes, actors, interfaces, and use cases.

一种方法将替代术语叠加在原始 UML 之上。例如，在 UP 中，当 UML 框在域模型中绘制时，它们称为域概念或概念类;Domain Model 显示了一个概念视角。在 UP 中，当 UML 框在 Design Model 中绘制时，它们称为设计类;Design Model （设计模型） 显示建模者所需的规范或实现透视图。

A method superimposes alternative terminology on top of the raw UML. For example, in the UP, when the UML boxes are drawn in the Domain Model, they are called domain concepts or conceptual classes; the Domain Model shows a conceptual perspective. In the UP, when UML boxes are drawn in the Design Model, they are called design classes; the Design Model shows a specification or implementation perspective, as desired by the modeler.

为了清楚起见，本书将使用与 UML 和 UP 一致的类相关术语，如下所示：

To keep things clear, this book will use class-related terms consistent with the UML and the UP, as follows:

• 概念类、现实世界的概念或事物。概念性或基本性的观点。UP 域模型包含概念类。

• Conceptual class real-world concept or thing. A conceptual or essential perspective. The UP Domain Model contains conceptual classes.

• 软件类 表示软件组件的规范或实现视角的类，与过程或方法无关。

• Software class a class representing a specification or implementation perspective of a software component, regardless of the process or method.

• Implementation class （实现类） 以特定 OO 语言 （如 Java） 实现的类。

• Implementation class a class implemented in a specific OO language such as Java.

UML 1 和 UML 2

UML 1 and UML 2

2004 年底，出现了 UML 的一个主要新版本，即 UML 2。本文基于 UML 2;事实上，这里使用的符号是与 UML 2 规范团队的关键成员一起仔细审查的。

Towards the end of 2004 a major new release of the UML emerged, UML 2. This text is based on UML 2; indeed, the notation used here was carefully reviewed with key members of the UML 2 specification team.

为什么我们在几章中没有看到太多的 UML？

Why Won't We See Much UML for a Few Chapters?

这主要不是一本 UML 表示法书，而是一本探索在 OOA/D 和相关需求分析的上下文中应用 UML、模式和迭代过程的更大图景的书。OOA/D 之前通常进行需求分析。因此，前几章介绍了用例和需求分析的重要主题，然后是关于 OOA/D 和更多 UML 细节的章节。

This is not primarily a UML notation book, but one that explores the larger picture of applying the UML, patterns, and an iterative process in the context of OOA/D and related requirements analysis. OOA/D is normally preceded by requirements analysis. Therefore, the initial chapters introduce the important topics of use cases and requirements analysis, which are then followed by chapters on OOA/D and more UML details.

1.7. 可视化建模是一件好事

1.7. Visual Modeling is a Good Thing

冒着显而易见的风险，绘制或阅读 UML 意味着我们更直观地工作，利用我们大脑的力量来快速掌握（主要是）二维盒线符号中的符号、单位和关系。

At the risk of stating the blindingly obvious, drawing or reading UML implies we are working more visually, exploiting our brain's strength to quickly grasp symbols, units, and relationships in (predominantly) 2D box-and-line notations.

这个古老而简单的想法经常在所有 UML 细节和工具中丢失。不应该！图表帮助我们看到或探索更多的大局以及分析或软件元素之间的关系，同时允许我们忽略或隐藏无趣的细节。这就是 UML 或任何图表语言的简单而本质的价值。

This old, simple idea is often lost among all the UML details and tools. It shouldn't be! Diagrams help us see or explore more of the big picture and relationships between analysis or software elements, while allowing us to ignore or hide uninteresting details. That's the simple and essential value of the UMLor any diagramming language.

1.8. 历史

1.8. History

OOA/D 的历史有很多分支，这个简短的概要并不能公正地对待所有贡献者。1960 年代和 1970 年代见证了 OO 编程语言的出现，例如 Simula 和 Smalltalk，其主要贡献者包括 Kristen Nygaard，尤其是创立了 Smalltalk 的富有远见的计算机科学家 Alan Kay。Kay 创造了面向对象编程和个人计算这两个术语，并在 Xerox PARC 期间帮助整合了现代 PC 的思想。^[2]

The history of OOA/D has many branches, and this brief synopsis can't do justice to all the contributors. The 1960s and 1970s saw the emergence of OO programming languages, such as Simula and Smalltalk, with key contributors such as Kristen Nygaard and especially Alan Kay, the visionary computer scientist who founded Smalltalk. Kay coined the terms object-oriented programming and personal computing, and helped pull together the ideas of the modern PC while at Xerox PARC.^[2]

^[2] Kay 在 1960 年代还是一名研究生时就开始研究 OO 和 PC。1979 年 12 月，在苹果伟大的杰夫·拉斯金（Mac 的主要创造者）的推动下，苹果的联合创始人兼首席执行官史蒂夫·乔布斯 （Steve Jobs） 拜访了施乐 PARC 的 Alan Kay 和研究团队（包括 Kay 愿景的实现者 Dan Ingalls），以演示 Smalltalk 个人电脑。他所看到的位图重叠窗口、OO 编程和联网 PC 的图形 UI 震惊了她带着新的愿景（Raskin 所希望的）回到了 Apple，Apple Lisa 和 Macintosh 诞生了。

^[2] Kay started work on OO and the PC in the 1960s, while a graduate student. In December 1979at the prompting of Apple's great Jef Raskin (the lead creator of the Mac)Steve Jobs, co-founder and CEO of Apple, visited Alan Kay and research teams (including Dan Ingalls, the implementor of Kay's vision) at Xerox PARC for a demo of the Smalltalk personal computer. Stunned by what he sawa graphical UI of bitmapped overlapping windows, OO programming, and networked PCshe returned to Apple with a new vision (the one Raskin hoped for), and the Apple Lisa and Macintosh were born.

但 OOA/D 在那个时期是非正式的，直到 1982 年，OOD 才作为一个独立的话题出现。当 Grady Booch（也是 UML 的创始人）写了第一篇题为“面向对象设计”的论文时，这个里程碑就出现了，这可能是 [Booch82] 这个术语的创造。许多其他著名的 OOA/D 先驱在 1980 年代发展了他们的想法：Kent Beck、Peter Coad、Don Firesmith、Ivar Jacobson（UML 创始人）、Steve Mellor、Bertrand Meyer、Jim Rumbaugh（UML 创始人）和 Rebecca Wirfs-Brock 等。Meyer 于 1988 年出版了一本早期有影响力的书籍，《面向对象的软件构造》。同年，Mellor 和 Schlaer 出版了《面向对象的系统分析》，创造了面向对象的分析一词。Peter Coad 在 1980 年代后期创建了一个完整的 OOA/D 方法，并于 1990 年和 1991 年出版了两卷《面向对象的分析》和《面向对象的设计》。同样在 1990 年，Wirfs-Brock 和其他人在他们流行的 Designing Object-Oriented Software 中描述了责任驱动的 OOD 设计方法。1991 年出版了两本非常受欢迎的 OOA/D 书籍。其中一篇描述了 Rumbaugh 等人的 OMT 方法，即面向对象的建模和设计。另一个描述了 Booch 方法，即 Object-Oriented Design with Applications。1992 年，Jacobson 出版了流行的面向对象的软件工程，它不仅促进了 OOA/D，还促进了需求的用例。

But OOA/D was informal through that period, and it wasn't until 1982 that OOD emerged as a topic in its own right. This milestone came when Grady Booch (also a UML founder) wrote the first paper titled Object-Oriented Design, probably coining the term [Booch82]. Many other well-known OOA/D pioneers developed their ideas during the 1980s: Kent Beck, Peter Coad, Don Firesmith, Ivar Jacobson (a UML founder), Steve Mellor, Bertrand Meyer, Jim Rumbaugh (a UML founder), and Rebecca Wirfs-Brock, among others. Meyer published one of the early influential books, Object-Oriented Software Construction, in 1988. And Mellor and Schlaer published Object-Oriented Systems Analysis, coining the term object-oriented analysis, in the same year. Peter Coad created a complete OOA/D method in the late 1980s and published, in 1990 and 1991, the twin volumes Object-Oriented Analysis and Object-Oriented Design. Also in 1990, Wirfs-Brock and others described the responsibility-driven design approach to OOD in their popular Designing Object-Oriented Software. In 1991 two very popular OOA/D books were published. One described the OMT method, Object-Oriented Modeling and Design, by Rumbaugh et al. The other described the Booch method, Object-Oriented Design with Applications. In 1992, Jacobson published the popular Object-Oriented Software Engineering, which promoted not only OOA/D, but use cases for requirements.

UML 始于 Booch 和 Rumbaugh 于 1994 年的努力，不仅是为了创建一种通用符号，而且是将他们的两种方法（Booch 和 OMT 方法）结合起来。因此，今天 UML 的第一个公开草案被呈现为统一方法。很快，Objectory 方法的创造者 Ivar Jacobson 也加入了 Rational Corporation，作为一个团体，他们被称为三个朋友。正是在这一点上，他们决定缩小他们的工作范围，并专注于一种常见的图表表示法 UML，而不是一种常见的方法。这不仅是一项划定范围的努力;对象管理组（OMG，面向对象相关标准的行业标准机构）被各种工具供应商说服，认为需要一个开放标准。因此，这个过程开始了，由 Mary Loomis 和 Jim Odell 主持的 OMG 工作组组织了导致 1997 年 UML 1.0 的初步工作。许多其他人为 UML 做出了贡献，也许最著名的是 Cris Kobryn，他是 UML 不断改进的领导者。

The UML started as an effort by Booch and Rumbaugh in 1994 not only to create a common notation, but to combine their two methodsthe Booch and OMT methods. Thus, the first public draft of what today is the UML was presented as the Unified Method. They were soon joined at Rational Corporation by Ivar Jacobson, the creator of the Objectory method, and as a group came to be known as the three amigos. It was at this point that they decided to reduce the scope of their effort, and focus on a common diagramming notationthe UMLrather than a common method. This was not only a de-scoping effort; the Object Management Group (OMG, an industry standards body for OO-related standards) was convinced by various tool vendors that an open standard was needed. Thus, the process opened up, and an OMG task force chaired by Mary Loomis and Jim Odell organized the initial effort leading to UML 1.0 in 1997. Many others contributed to the UML, perhaps most notably Cris Kobryn, a leader in its ongoing refinement.

UML 已成为面向对象建模的事实和法律标准图表表示法，并在新的 OMG UML 版本中不断得到完善，www.omg.org 或 www.uml.org 版本提供。

The UML has emerged as the de facto and de jure standard diagramming notation for object-oriented modeling, and has continued to be refined in new OMG UML versions, available at www.omg.org or www.uml.org.

1.9. 推荐资源

1.9. Recommended Resources

在后面的章节中，将推荐与特定主题相关的各种 OOA/D 文本，例如 OO 设计。历史部分的书籍都值得研究，并且仍然适用于其核心建议。

Various OOA/D texts are recommended in later chapters, in relation to specific subjects, such as OO design. The books in the history section are all worth studyand still applicable regarding their core advice.

一个非常可读和流行的基本 UML 表示法的摘要是 Martin Fowler 的 UML Distilled。强烈推荐;Fowler 以务实和“敏捷”的态度写了许多有用的书。

A very readable and popular summary of essential UML notation is UML Distilled by Martin Fowler. Highly recommended; Fowler has written many useful books, with a practical and "agile" attitude.

有关 UML 表示法的详细讨论，Rumbaugh 的 The Unified Modeling Language Reference Manual 是值得的。请注意，本文不是为了学习如何进行对象建模，也不是 OOA/Dit 的 UML 表示法参考。

For a detailed discussion of UML notation, The Unified Modeling Language Reference Manual by Rumbaugh is worthwhile. Note that this text isn't meant for learning how to do object modeling or OOA/Dit's a UML notation reference.

有关 UML 当前版本的明确说明，请参见在线 UML 基础结构规范和 UML 上层结构规范，www.uml.org 或 www.omg.org。

For the definitive description of the current version of the UML, see the on-line UML Infrastructure Specification and UML Superstructure Specification at www.uml.org or www.omg.org.

Scott Ambler 的 Agile Modeling 中介绍了敏捷建模精神下的可视化 UML 建模。另请参见 www.agilemodeling.com。

Visual UML modeling in an agile modeling spirit is described in Agile Modeling by Scott Ambler. See also www.agilemodeling.com.

在 www.cetus-links.org 和 www.iturls.com 中有大量指向 OOA/D 方法的链接（英文的 “Software Engineering” 小节，而不是中文部分）。

There is a large collection of links to OOA/D methods at www.cetus-links.org and www.iturls.com (the large English "Software Engineering" subsection, rather than the Chinese section).

关于软件模式的书籍很多，但开创性的经典著作是 Gamma、Helm、Johnson 和 Vlissides 合著的 Design Patterns。对于那些学习对象设计的人来说，这确实是必读的。但是，它不是介绍性文本，最好在熟悉对象设计和编程的基础知识后阅读。另请参阅 www.hillside.net 和 www.iturls.com（英文的 “Software Engineering” 小节）以获取许多模式站点的链接。

There are many books on software patterns, but the seminal classic is Design Patterns by Gamma, Helm, Johnson, and Vlissides. It is truly required reading for those studying object design. However, it is not an introductory text and is best read after one is comfortable with the fundamentals of object design and programming. See also www.hillside.net and www.iturls.com (the English "Software Engineering" subsection) for links to many pattern sites.

第 2 章.迭代、进化和敏捷

Chapter 2. Iterative, Evolutionary, and Agile

您应该只在希望成功的项目上使用迭代开发。

马丁·福勒

You should use iterative development only on projects that you want to succeed.

Martin Fowler

介绍

Introduction

迭代开发是 OOA/D 最佳实践的核心，本书对此进行了介绍。敏捷建模等敏捷实践是以有效方式应用 UML 的关键。本章介绍这些主题，以及作为一种相对流行的样本迭代方法的 Unified Process。

Iterative development lies at the heart of how OOA/D is best practiced and is presented in this book. Agile practices such as Agile Modeling are key to applying the UML in an effective way. This chapter introduces these subjects, and the Unified Process as a relatively popular sample iterative method.

与顺序或“瀑布”生命周期相反，迭代和进化开发涉及在重复周期中对部分系统进行早期编程和测试。它还通常假设开发在详细定义所有需求之前就开始了;反馈用于阐明和改进不断发展的规范。

Iterative and evolutionary development contrasted with a sequential or "waterfall" lifecycleinvolves early programming and testing of a partial system, in repeating cycles. It also normally assumes development starts before all the requirements are defined in detail; feedback is used to clarify and improve the evolving specifications.

我们依靠简短的快速开发步骤、反馈和调整来阐明需求和设计。相比之下，瀑布值促进了编程之前的大型前期推测需求和设计步骤。一致地，成功/失败研究表明，瀑布流与软件项目的最高失败率密切相关，并且在历史上由于信念或道听途说而不是具有统计意义的证据而被推广。研究表明，迭代方法与更高的成功率和生产率以及更低的缺陷水平相关。

We rely on short quick development steps, feedback, and adaptation to clarify the requirements and design. To contrast, waterfall values promoted big up-front speculative requirements and design steps before programming. Consistently, success/failure studies show that the waterfall is strongly associated with the highest failure rates for software projects and was historically promoted due to belief or hearsay rather than statistically significant evidence. Research demonstrates that iterative methods are associated with higher success and productivity rates, and lower defect levels.

2.1. 什么是 UP？其他方法可以互补吗？

2.1. What is the UP? Are Other Methods Complementary?

软件开发过程描述了一种构建、部署和可能维护软件的方法。统一流程 [JBR99] 已成为构建面向对象系统的流行迭代软件开发流程。特别是，Rational Unified Process 或 RUP [Kruchten00]，它是 Unified Process 的详细改进，已被广泛采用。

A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process [JBR99] has emerged as a popular iterative software development process for building object-oriented systems. In particular, the Rational Unified Process or RUP [Kruchten00], a detailed refinement of the Unified Process, has been widely adopted.

因为统一流程 （UP） 对于使用 OOA/D 的项目来说是一个相对流行的迭代过程，并且因为必须使用一些过程来引入主题，所以 UP 塑造了这本书的结构。此外，由于 UP 很常见并促进了广泛认可的最佳实践，因此行业专业人士了解它和进入劳动力市场的学生了解它很有用。

Because the Unified Process (UP) is a relatively popular iterative process for projects using OOA/D, and because some process must be used to introduce the subject, the UP shapes the book's structure. Also, since the UP is common and promotes widely recognized best practices, it's useful for industry professionals to know it, and students entering the workforce to be aware of it.

UP 非常灵活和开放，并鼓励包括来自其他迭代方法的熟练实践，例如来自极限编程 （XP）、Scrum 等。例如，XP 的测试驱动开发、重构和持续集成实践可以适应 UP 项目。Scrum 的公共项目室（“作战室”）和日常 Scrum 会议练习也可以。引入 UP 并不意味着要低估这些其他方法的价值，恰恰相反。在我的咨询工作中，我鼓励客户理解并采用来自多种方法的有用技术，而不是教条式的“我的方法比你的方法好”的心态。

The UP is very flexible and open, and encourages including skillful practices from other iterative methods, such as from Extreme Programming (XP), Scrum, and so forth. For example, XP's test-driven development, refactoring and continuous integration practices can fit within a UP project. So can Scrum's common project room ("war room") and daily Scrum meeting practice. Introducing the UP is not meant to downplay the value of these other methodsquite the opposite. In my consulting work, I encourage clients to understand and adopt a blend of useful techniques from several methods, rather than a dogmatic "my method is better than your method" mentality.

UP 将普遍接受的最佳实践（例如迭代生命周期和风险驱动型开发）组合成一个有凝聚力且文档齐全的流程描述。

The UP combines commonly accepted best practices, such as an iterative lifecycle and risk-driven development, into a cohesive and well-documented process description.

总而言之，本章包括 UP 的介绍，原因有三：

To summarize, this chapter includes an introduction to the UP for three reasons:

如果我不关心 UP 怎么办？

What If I Don't Care About the UP?

UP 用作示例过程，在其中探索迭代和进化需求分析和 OOA/D，因为有必要在某个过程的上下文中引入主题。

The UP is used as an example process within which to explore iterative and evolutionary requirements analysis and OOA/D, since it's necessary to introduce the subject in the context of some process.

但是，本书的中心思想如何使用对象思考和设计、应用 UML、使用设计模式、敏捷建模、进化需求分析、编写用例等独立于任何特定过程，并适用于许多现代迭代、进化和敏捷方法，例如 Scrum、精益开发、DSDM、功能驱动开发、自适应软件开发等。

But the central ideas of this bookhow to think and design with objects, apply UML, use design patterns, agile modeling, evolutionary requirements analysis, writing use cases, and so forthare independent of any particular process, and apply to many modern iterative, evolutionary, and agile methods, such as Scrum, Lean Development, DSDM, Feature-Driven Development, Adaptive Software Development, and more.

2.2. 什么是迭代和进化发展？

2.2. What is Iterative and Evolutionary Development?

UP 和大多数其他现代方法中的一个关键实践是迭代开发。在这种生命周期方法中，开发被组织成一系列简短的、固定长度的（例如，三周）的小型项目，称为迭代;每个系统的结果都是一个经过测试、集成且可执行的 partial 系统。每个迭代都包括其自己的需求分析、设计、实施和测试活动。

A key practice in both the UP and most other modern methods is iterative development. In this lifecycle approach, development is organized into a series of short, fixed-length (for example, three-week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable partial system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.

迭代生命周期基于系统通过多次迭代的连续扩展和细化，以循环反馈和适应为核心驱动力，以收敛到合适的系统。系统随着时间的推移、一次又一次的迭代而逐渐增长，因此这种方法也被称为迭代和增量开发（见图 2.1）。因为反馈和适应会发展规范和设计，所以它也被称为迭代和进化开发。

The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development (see Figure 2.1). Because feedback and adaptation evolve the specifications and design, it is also known as iterative and evolutionary development.

图 2.1.迭代和进化发展。

[查看全尺寸图片]

早期的迭代过程思想被称为螺旋发展和进化发展 [Boehm88， Gilb88]。

Early iterative process ideas were known as spiral development and evolutionary development [Boehm88, Gilb88].

请注意，在这个例子中，既没有急于编写代码，也没有一个漫长的设计步骤，试图在编程之前完善设计的所有细节。关于使用粗略而快速的 UML 绘图进行可视化建模的设计，我们做了一个 “小 ”的预想;也许是半天或一整天，由开发人员在白板上成对进行设计工作 UML 草图。

Notice in this example that there is neither a rush to code, nor a long drawn-out design step that attempts to perfect all details of the design before programming. A "little" forethought regarding the design with visual modeling using rough and fast UML drawings is done; perhaps a half or full day by developers doing design work UML sketching in pairs at whiteboards.

每次迭代的结果都是一个可执行但不完整的系统;它尚未准备好交付到生产环境中。在多次迭代之前，系统可能不符合生产部署的条件;例如，10 次或 15 次迭代。

The result of each iteration is an executable but incomplete system; it is not ready to deliver into production. The system may not be eligible for production deployment until after many iterations; for example, 10 or 15 iterations.

迭代的输出不是实验性或一次性原型，迭代开发也不是原型设计。相反，输出是最终系统的生产级子集。

The output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system.

如何处理迭代项目的更改？

How to Handle Change on an Iterative Project?

一本讨论迭代开发的书的副标题是 Embrace Change [Beck00]。这句话让人想起迭代开发的一个关键态度：迭代和进化开发不是通过尝试（未成功）在实现之前（在“瀑布”过程中）完全正确地指定、冻结和“签署”冻结的需求集和设计来对抗软件开发中不可避免的变化，而是基于一种接受变化和适应的态度，将其视为不可避免的，而且确实是必不可少的驱动力。

The subtitle of one book that discusses iterative development is Embrace Change [Beck00]. This phrase is evocative of a key attitude of iterative development: Rather than fighting the inevitable change that occurs in software development by trying (unsuccessfully) to fully and correctly specify, freeze, and "sign off" on a frozen requirement set and design before implementation (in a "waterfall" process), iterative and evolutionary development is based on an attitude of embracing change and adaptation as unavoidable and indeed essential drivers.

这并不是说迭代开发和 UP 鼓励不受控制和反应性的 “特性蠕变” 驱动的过程。随后的章节探讨了 UP 如何平衡一方面达成一致和稳定一组需求的需求，另一方面随着利益相关者澄清他们的愿景或市场变化而不断变化的需求。

This is not to say that iterative development and the UP encourage an uncontrolled and reactive "feature creep"-driven process. Subsequent chapters explore how the UP balances the needon the one handto agree upon and stabilize a set of requirements, withon the other handthe reality of changing requirements, as stakeholders clarify their vision or the marketplace changes.

每次迭代都涉及选择一小部分需求，并快速设计、实施和测试。在早期迭代中，需求和设计的选择可能并不完全是最终想要的。但是，在所有需求最终确定之前，或者在整个设计被推测性定义之前，迅速迈出一小步的行为会导致来自用户、开发人员和测试（例如负载和可用性测试）的快速反馈反馈。

Each iteration involves choosing a small subset of the requirements, and quickly designing, implementing, and testing. In early iterations the choice of requirements and design may not be exactly what is ultimately desired. But the act of swiftly taking a small step, before all requirements are finalized, or the entire design is speculatively defined, leads to rapid feedbackfeedback from the users, developers, and tests (such as load and usability tests).

而这种早期反馈是值得的;该团队不是推测完整、正确的需求或设计，而是从实际构建和测试中挖掘反馈，以获得关键的实践见解和修改或调整对需求或设计的理解的机会。最终用户有机会快速看到部分系统并说：“是的，这就是我要求的，但现在我尝试了，我真正想要的是略有不同的东西。^[1]这个“是的......但是“过程并不是失败的标志;相反，早期和频繁的“是的......但是“是一种取得进展并发现对利益相关者真正有价值的方法。然而，这并不是对开发人员不断改变方向的混乱和反应性开发的认可，中间道路是可能的。

And this early feedback is worth its weight in gold; rather than speculating on the complete, correct requirements or design, the team mines the feedback from realistic building and testing something for crucial practical insight and an opportunity to modify or adapt understanding of the requirements or design. End-users have a chance to quickly see a partial system and say, "Yes, that's what I asked for, but now that I try it, what I really want is something slightly different."^[1] This "yes…but" process is not a sign of failure; rather, early and frequent structured cycles of "yes…buts" are a skillful way to make progress and discover what is of real value to the stakeholders. Yet this is not an endorsement of chaotic and reactive development in which developers continually change directiona middle way is possible.

^[1] 或者更有可能的是，“你不明白我想要什么！

^[1] Or more likely, "You didn't understand what I wanted!"

除了需求澄清之外，负载测试等活动还将证明部分设计和实现是否走在正确的道路上，或者在下一次迭代中是否需要更改核心架构。最好尽早解决和证明风险和关键的设计决策，而不是晚点，迭代开发为此提供了机制。

In addition to requirements clarification, activities such as load testing will prove if the partial design and implementation are on the right path, or if in the next iteration, a change in the core architecture is required. Better to resolve and prove the risky and critical design decisions early rather than lateand iterative development provides the mechanism for this.

因此，工作会通过一系列结构化的构建-反馈-适应周期进行。毫不奇怪，在早期迭代中，与系统的 “真实路径” （就其最终需求和设计而言） 的偏差将大于后续迭代。随着时间的推移，系统会向这条路径收敛，如图 2.2 所示。

Consequently, work proceeds through a series of structured build-feedback-adapt cycles. Not surprisingly, in early iterations the deviation from the "true path" of the system (in terms of its final requirements and design) will be larger than in later iterations. Over time, the system converges towards this path, as illustrated in Figure 2.2.

图 2.2.迭代反馈和进化导致所需的系统。随着时间的推移，需求和设计的不稳定性会降低。

[查看全尺寸图片]

迭代开发有什么好处吗？

Are There Benefits to Iterative Development?

是的。优势包括：

Yes. Benefits include:

• 减少项目失败、提高生产力和降低缺陷率;通过对迭代和进化方法的研究显示

• less project failure, better productivity, and lower defect rates; shown by research into iterative and evolutionary methods

• 尽早而不是延迟缓解高风险（技术、要求、目标、可用性等）

• early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth)

• 早期可见的进展

• early visible progress

• 早期反馈、用户参与和适应，从而形成更紧密地满足利益相关者实际需求的精细系统

• early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders

• 可控的复杂性;团队不会被 “分析瘫痪” 或非常漫长而复杂的步骤所淹没

• managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and complex steps

• 迭代中的学习可以有条不紊地用于改进开发过程本身，逐个迭代

• the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration

迭代应该多长时间？什么是迭代时间盒？

How Long Should an Iteration Be? What is Iteration Timeboxing?

大多数迭代方法建议的迭代长度在 2 到 6 周之间。小步骤、快速反馈和适应是迭代开发的中心思想;长时间迭代颠覆了迭代开发的核心动机，增加了项目风险。在短短一周内，通常很难完成足够的工作来获得有意义的吞吐量和反馈;超过 6 周，复杂性变得相当庞大，反馈被延迟。一个非常长的时间盒迭代错过了迭代开发的重点。短就是好。

Most iterative methods recommend an iteration length between two and six weeks. Small steps, rapid feedback, and adaptation are central ideas in iterative development; long iterations subvert the core motivation for iterative development and increase project risk. In only one week it is often difficult to complete sufficient work to get meaningful throughput and feedback; more than six weeks, and the complexity becomes rather overwhelming, and feedback is delayed. A very long timeboxed iteration misses the point of iterative development. Short is good.

一个关键思想是迭代是有时间限制的，或者说长度是固定的。例如，如果下一次迭代选择为三周，则必须通过计划的日期日期延迟来集成、测试和稳定部分系统，这是非法的。如果似乎很难满足截止日期，建议的应对措施是从迭代中删除任务或需求，并将它们包含在将来的迭代中，而不是推迟完成日期。

A key idea is that iterations are timeboxed, or fixed in length. For example, if the next iteration is chosen to be three weeks long, then the partial system must be integrated, tested, and stabilized by the scheduled datedate slippage is illegal. If it seems that it will be difficult to meet the deadline, the recommended response is to de-scoperemove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date.

2.3. 瀑布生命周期呢？

2.3. What About the Waterfall Lifecycle?

在瀑布式（或顺序）生命周期过程中，尝试在编程之前定义（详细）所有或大部分需求。通常，在编程之前创建一个全面的设计（或一组 smodel）。同样，试图在开始时定义一个 “可靠 ”的计划或时间表，而不是它将是。

In a waterfall (or sequential) lifecycle process there is an attempt to define (in detail) all or most of the requirements before programming. And often, to create a thorough design (or set of smodels) before programming. Likewise, an attempt to define a "reliable" plan or schedule near the startnot that it will be.

研究（从许多来源收集并在 [Larman03] 和 [LB03] 中总结）现在最终表明，具有讽刺意味的是，1960 年代和 1970 年代应用瀑布的建议对于大多数软件项目来说是一种糟糕的做法，而不是一种熟练的方法。它与高失败率、低生产率和更高的缺陷率（与迭代项目相比）密切相关。平均而言，瀑布流要求中 45% 的特征从未使用过，早期瀑布流计划和估计值与最终实际值相差高达 400%。

Research (collected from many sources and summarized in [Larman03] and [LB03]) now shows conclusively that the 1960s and 1970s-era advice to apply the waterfall wasironicallya poor practice for most software projects, rather than a skillful approach. It is strongly associated with high rates of failure, lower productivity, and higher defect rates (than iterative projects). On average, 45% of the features in waterfall requirements are never used, and early waterfall schedules and estimates vary up to 400% from the final actuals.

事后看来，我们现在知道瀑布式建议是基于猜测和道听途说，而不是基于证据的实践。相比之下，迭代和进化实践有证据支持，研究表明它们不易失败，并且与更高的生产力和缺陷率相关。

In hindsight, we now know that waterfall advice was based on speculation and hearsay, rather than evidence-based practices. In contrast, iterative and evolutionary practices are backed by evidencestudies show they are less failure prone, and associated with better productivity and defect rates.

指南：不要让瀑布式思维侵入迭代或 UP 项目

Guideline: Don't Let Waterfall Thinking Invade an Iterative or UP Project

我需要强调的是，“瀑布式思维”经常被错误地侵入到所谓的迭代或 UP 项目中。诸如“让我们在开始编程之前编写所有用例”或“让我们在开始编程之前在 UML 中做许多详细的 OO 模型”之类的想法是错误地叠加在 UP 上的不健康的瀑布思维的例子。UP 的创建者将这种误解大前期分析和建模列为其失败的关键原因 [KL01]。

I need to emphasize that "waterfall thinking" often incorrectly still invades a so-called iterative or UP project. Ideas such as "let's write all the use cases before starting to program" or "let's do many detailed OO models in UML before starting to program" are examples of unhealthy waterfall thinking incorrectly super imposed on the UP. The creators of the UP cite this misunderstandingbig up-front analysis and modelingas a key reason for its failed adoption [KL01].

为什么瀑布式如此容易失败？

Why is the Waterfall so Failure-Prone?

对于瀑布流为何如此容易失败，没有一个简单的答案，但它与许多失败软件项目背后的一个关键错误假设密切相关，即规范是可预测的和稳定的，并且可以在开始时正确定义，更改率低。事实证明，这远非准确，而且是一个代价高昂的误解。Boehm 和 Papaccio 的一项研究表明，一个典型的软件项目的需求发生了 25% 的变化 [BP88]。这一趋势在另一项针对数千个软件项目的主要研究中得到了证实，大型项目的变更率甚至更高 35% 到 50%，如图 2.3 所示 [Jones97]。

There isn't one simple answer to why the waterfall is so failure-prone, but it is strongly related to a key false assumption underlying many failed software projectsthat the specifications are predictable and stable and can be correctly defined at the start, with low change rates. This turns out to be far from accurateand a costly misunderstanding. A study by Boehm and Papaccio showed that a typical software project experienced a 25% change in requirements [BP88]. And this trend was corroborated in another major study of thousands of software projects, with change rates that go even higher35% to 50% for large projectsas illustrated in Figure 2.3 [Jones97].

这些是极高的更改率。这些数据表明，任何有经验的开发人员或经理都痛苦地意识到，软件开发（平均而言）是一个高度变化和不稳定的领域，也称为新产品开发领域。软件通常不是一个可预测或大规模制造的低变化领域，在这些领域中，在开始时可以有效地定义所有稳定的规范和可靠的计划。

These are extremely high change rates. What this data showsas any experienced developer or manager is painfully awareis that software development is (on average) a domain of high change and instabilityalso known as the domain of new product development. Software is not usually a domain of predictable or mass manufacturinglow-change areas where it is possible and efficient to define all the stable specifications and reliable plans near the start.

因此，任何基于事物长期稳定（即瀑布）假设的分析、建模、开发或管理实践都是有根本缺陷的。变化是软件项目的常态。迭代和进化方法根据反馈假设并接受部分和不断发展的规范、模型和计划的变化和适应。

Thus, any analysis, modeling, development, or management practice based on the assumption that things are long-term stable (i.e., the waterfall) is fundamentally flawed. Change is the constant on software projects. Iterative and evolutionary methods assume and embrace change and adaptation of partial and evolving specifications, models, and plans based on feedback.

需要反馈和适应

The Need for Feedback and Adaptation

在复杂、不断变化的系统中（例如大多数软件项目），反馈和适应是成功的关键因素。

In complex, changing systems (such as most software projects) feedback and adaptation are key ingredients for success.

• 来自早期开发的反馈，程序员尝试阅读规范，以及客户演示以完善需求。

• Feedback from early development, programmers trying to read specifications, and client demos to refine the requirements.

• 来自测试和开发人员的反馈，以优化设计或模型。

• Feedback from tests and developers to refine the design or models.

• 来自团队处理早期功能以优化计划和估计的进度的反馈。

• Feedback from the progress of the team tackling early features to refine the schedule and estimates.

• 来自客户和市场的反馈，以重新确定下一次迭代中要解决的功能的优先级。

• Feedback from the client and marketplace to re-prioritize the features to tackle in the next iteration.

2.4. 如何进行迭代和进化分析和设计？

2.4. How to do Iterative and Evolutionary Analysis and Design?

这个介绍可能给人的印象是，在编程之前进行分析和设计没有价值，但这是一种极端的误解，就像认为“完整”的前期分析是熟练的一样极端。有一条中间道路。这是一个简短的示例（不是配方），说明它如何在运行良好的 UP 项目中工作。这假设在交付之前，项目最终将有 20 次迭代：

This introduction may have given the impression that there is no value in analysis and design before programming, but that is a misunderstanding as extreme as thinking that "complete" up-front analysis is skillful. There is a middle way. Here's a short example (not a recipe) of how it can work on a well-run UP project. This assumes there will ultimately be 20 iterations on the project before delivery:

图 2.5 说明了 20 次迭代项目的方法。

Figure 2.5 illustrates the approach for a 20-iteration project.

图 2.5.项目中序列图的 UML 草图。

[查看全尺寸图片]

通过这种方式，经过几次早期探索性开发迭代后，团队可以更可靠地回答 “什么、多少、何时”。

In this way, after a few iterations of early exploratory development, there comes a point when the team can more reliably answer "what, how much, when."

2.5. 什么是风险驱动型迭代规划和客户驱动型迭代规划？

2.5. What is Risk-Driven and Client-Driven Iterative Planning?

UP（以及大多数新方法）鼓励风险驱动和客户驱动的迭代规划相结合。这意味着早期迭代的目标被选择为 1） 识别并降低最高风险，以及 2） 构建客户最关心的可见功能。

The UP (and most new methods) encourage a combination of risk-driven and client-driven iterative planning. This means that the goals of the early iterations are chosen to 1) identify and drive down the highest risks, and 2) build visible features that the client cares most about.

风险驱动的迭代开发更具体地包括以架构为中心的迭代开发实践，这意味着早期迭代侧重于构建、测试和稳定核心架构。为什么？因为没有可靠的架构是一种常见的高风险。

Risk-driven iterative development includes more specifically the practice of architecture-centric iterative development, meaning that early iterations focus on building, testing, and stabilizing the core architecture. Why? Because not having a solid architecture is a common high risk.

2.6. 什么是敏捷方法和态度？

2.6. What are Agile Methods and Attitudes?

敏捷开发方法通常应用有时间限制的迭代和渐进式开发，采用适应性规划，促进增量交付，并包括其他价值和实践，鼓励敏捷、快速和灵活地响应变化。

Agile development methods usually apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and include other values and practices that encourage agilityrapid and flexible response to change.

图 2.4.进化分析和设计在早期迭代中占大多数。

[查看全尺寸图片]

由于具体实践差异很大，因此无法准确定义敏捷方法。然而，具有计划、需求和设计的渐进式改进的短时间盒迭代是这些方法共享的基本实践。此外，它们还促进了反映简单、轻便、沟通、自组织团队等敏捷敏感性的实践和原则。

It is not possible to exactly define agile methods, as specific practices vary widely. However, short timeboxed iterations with evolutionary refinement of plans, requirements, and design is a basic practice the methods share. In addition, they promote practices and principles that reflect an agile sensibility of simplicity, lightness, communication, self-organizing teams, and more.

Scrum 敏捷方法的示例实践包括一个公共项目工作室和自组织团队，这些团队通过每日站立会议进行协调，每个成员回答四个特殊问题。极限编程 （XP） 方法的示例实践包括成对编程和测试驱动开发。

Example practices from the Scrum agile method include a common project workroom and self-organizing teams that coordinate through a daily stand-up meeting with four special questions each member answers. Example practices from the Extreme Programming (XP) method include programming in pairs and test-driven development.

任何迭代方法，包括 UP，都可以本着敏捷的精神应用。UP 本身也很灵活，鼓励“只要有效”的态度，包括 Scrum、XP 和其他方法的实践。

Any iterative method, including the UP, can be applied in an agile spirit. And the UP itself is flexible, encouraging a "whatever works" attitude to include practices from Scrum, XP, and other methods.

敏捷宣言和原则

The Agile Manifesto and Principles

敏捷宣言

敏捷原则

2001 年，一个对迭代和敏捷方法（创造了这个词）感兴趣的小组开会寻找共同点。由此诞生了敏捷联盟 （www.agilealliance.com），它提出了一个宣言和原则声明，以捕捉敏捷方法的精神。

In 2001 agroup interested in iterative and agile methods (coining the term) met to find common ground. Out of this came the Agile Alliance (www.agilealliance.com) with a manifesto and statement of principles to capture the spirit of agile methods.

2.7. 什么是敏捷建模？

2.7. What is Agile Modeling?

经验丰富的分析师和建模师都知道建模的秘诀：

Experienced analysts and modelers know the secret of modeling:

建模（草绘 UML 等）的目的主要是理解，而不是记录。

The purpose of modeling (sketching UML, …) is primarily to understand, not to document.

也就是说，建模行为本身可以而且应该提供一种方法来更好地理解问题或解决方案空间。从这个角度来看，“做 UML”（这实际上应该意味着“做 OOA/D”）的目的不是让设计师创建许多详细的 UML 图，然后交给程序员（这是一种非常不敏捷和瀑布导向的思维方式），而是快速探索（比使用代码更快）替代方案和通往良好 OO 设计的途径。

That is, the very act of modeling can and should provide a way to better understand the problem or solution space. From this viewpoint, the purpose of "doing UML" (which should really mean "doing OOA/D") is not for a designer to create many detailed UML diagrams that are handed off to a programmer (which is a very un-agile and waterfall-oriented mindset), but rather to quickly explore (more quickly than with code) alternatives and the path to a good OO design.

这种观点与敏捷方法一致，在《敏捷建模》一书 [Ambler02] 中被称为敏捷建模。它意味着许多实践和价值观，包括：

This view, consistent with agile methods, has been called agile modeling in the book (amazingly called) Agile Modeling [Ambler02]. It implies a number of practices and values, including:

• 采用敏捷方法并不意味着避免任何建模;这是一个误解。许多敏捷方法（例如功能驱动开发、DSDM 和 Scrum）通常包括重要的建模会话。即使是 XP 的创始人，也许是最著名的敏捷方法，但对建模的重视程度最低，也赞同 Amblerand 所描述的敏捷建模，多年来许多建模者都在实践这种敏捷建模。

• Adopting an agile method does not mean avoiding any modeling; that's a misunderstanding. Many agile methods, such as Feature-Driven Development, DSDM, and Scrum, normally include significant modeling sessions. Even the XP founders, from perhaps the most well-known agile method with the least emphasis on modeling, endorsed agile modeling as described by Amblerand practiced by many modelers over the years.

• 建模和模型的目的主要是支持理解和交流，而不是文档。

• The purpose of modeling and models is primarily to support understanding and communication, not documentation.

• 不要将 UML 建模或应用于所有或大部分软件设计。将简单或直接的设计问题推迟到编程解决它们时，同时进行编程和测试。对设计空间中较小比例的不常见、困难、棘手的部分进行建模和应用 UML。

• Don't model or apply the UML to all or most of the software design. Defer simple or straightforward design problems until programmingsolve them while programming and testing. Model and apply the UML for the smaller percentage of unusual, difficult, tricky parts of the design space.

• 使用最简单的工具。更喜欢支持快速输入和更改的“低能耗”创造力增强简单工具。此外，选择支持大型视觉空间的工具。例如，更喜欢在白板上绘制 UML 草图，并使用数码相机捕获图表。^[2]

  ^[2] 两个白板素描技巧：一：如果你没有足够的白板（你应该有很多大白板），另一种选择是“白板”塑料粘附板，它粘在墙上（带静电）以制作白板。北美的主要产品是 Avery Write-On 保鲜纸;欧洲的主要产品是 LegaMaster Magic-Chart。第二：白板图像的数码照片通常很差（由于反射）。不要使用闪光灯，但如果您需要清理图像，请使用软件“白板图像清理”应用程序来改进图像（就像我为这本书所做的那样）。

  • 这并不意味着 UML CASE 工具或文字处理器不能使用或没有价值，但特别是对于发现的创造性工作，在白板上绘制草图支持快速的创意流程和变化。无论采用何种技术，关键规则是易用性和敏捷性。

• Use the simplest tool possible. Prefer "low energy" creativity-enhancing simple tools that support rapid input and change. Also, choose tools that support large visual spaces. For example, prefer sketching UML on whiteboards, and capturing the diagrams with a digital camera.^[2]

  ^[2] Two whiteboard sketching tips: One: If you don't have enough whiteboards (and you should have many large ones), an alternative is "whiteboard" plastic cling sheets which cling to walls (with a static charge) to create whiteboards. The main product in North America is Avery Write-On Cling Sheets; the main product in Europe is LegaMaster Magic-Chart. Two: Digital photos of whiteboard images are often poor (due to reflection). Don't use a flash, but use a software "whiteboard image clean up" application to improve the images, if you need to clean them (as I did for this book).

  • This doesn't mean UML CASE tools or word processors can't be used or have no value, but especially for the creative work of discovery, sketching on whiteboards supports quick creative flow and change. The key rule is ease and agility, whatever the technology.

• 不要单独建模，而是在白板上成对（或三合会）建模，因为要意识到建模的目的是发现、理解和分享这种理解。在杆件之间旋转钢笔草绘，以便所有杆件都参与。

• Don't model alone, model in pairs (or triads) at the whiteboard, in the awareness that the purpose of modeling is to discover, understand, and share that understanding. Rotate the pen sketching across the members so that all participate.

• 并行创建模型。例如，在一个白板上开始绘制动态视图 UML 交互图，在另一个白板上开始绘制互补的静态视图 UML 类图。一起开发两个模型（两个视图），来回切换。

• Create models in parallel. For example, on one whiteboard start sketching a dynamic-view UML interaction diagram, and on another whiteboard, start sketching the complementary static-view UML class diagram. Develop the two models (two views) together, switching back and forth.

• 使用“足够好”的简单符号，同时用笔在白板上画草图。确切的 UML 细节并不重要，只要建模者彼此理解即可。坚持使用简单、常用的 UML 元素。

• Use "good enough" simple notation while sketching with a pen on whiteboards. Exact UML details aren't important, as long as the modelers understand each other. Stick to simple, frequently used UML elements.

• 要知道，所有模型都是不准确的，最终的代码或设计也会有所不同，有时与模型截然不同。只有经过测试的代码才能证明真正的设计;所有前面的图表都是不完整的提示，最好轻描淡写地视为一次性探索。

• Know that all models will be inaccurate, and the final code or design differentsometimes dramatically differentthan the model. Only tested code demonstrates the true design; all prior diagrams are incomplete hints, best treated lightly as throw-away explorations.

• 开发人员自己应该自己做 OO 设计建模，而不是创建图表，然后交给其他程序员来实现非敏捷的面向瀑布的实践示例。

• Developers themselves should do the OO design modeling, for themselves, not to create diagrams that are given to other programmers to implementan example of un-agile waterfall-oriented practices.

本书中的敏捷建模：为什么是 UML 草图的快照？

Agile Modeling in this Book: Why the Snapshots of UML Sketches?

在白板上进行 UML 草图建模是一种实践，许多开发人员多年来一直热情地指导和实践。然而，本书中的大多数 UML 图都给人的印象是我不是这样工作的，因为它们是用工具整齐地绘制的，以提高可读性。为了平衡这种印象，这本书偶尔会包括白板 UML 草图的数字快照图片。它牺牲了易读性，但提醒了敏捷建模是有用的，并且是案例研究背后的实际实践。

UML-sketch modeling on whiteboards is a practice Iand many developershave enthusiastically coached and practiced for years. Yet most of the UML diagrams in this book give the impression I don't work that way, because they've been drawn neatly with a tool, for readability. To balance that impression the book occasionally includes digital snapshot pictures of whiteboard UML sketches. It sacrifices legibility but reminds that agile modeling is useful and is the actual practice behind the case studies.

例如，图 2.5 是在我指导的一个项目上创建的未经编辑的 UML 草图。画画花了大约 20 分钟，周围站着四名开发人员。我们需要了解系统间的协作。将其整合在一起的行为为贡献独特的见解并达成共识提供了一个环境。这捕捉到了敏捷建模者如何应用 UML 的感觉。

For example, Figure 2.5 is an unedited UML sketch created on a project I was coaching. It took about 20 minutes to draw, with four developers standing around. We needed to understand the inter-system collaboration. The act of drawing it together provided a context to contribute unique insights and reach shared understanding. This captures the feel of how agile modelers apply the UML.

2.8. 什么是 Agile UP？

2.8. What is an Agile UP?

UP 的创建者并不是说它是沉重或不敏捷的，尽管它大量的可选活动和工件导致了一些人留下这种印象，这是可以理解的。相反，它本着适应性和轻便敏捷 UP 的精神被采用和应用。具体应用方式的一些示例：

The UP was not meant by its creators to be heavy or un-agile, although its large optional set of activities and artifacts have understandably led some to that impression. Rather, it was meant to be adopted and applied in the spirit of adaptability and lightnessan agile UP. Some examples of how this applies:

• 首选一小部分 UP 活动和工件。有些项目会比其他项目受益更多，但总的来说，请保持简单。请记住，所有 UP 工件都是可选的，除非它们能增加价值，否则请避免创建它们。专注于早期编程，而不是早期记录。

  定制 UP，第 37 页

  
  
  

• Prefer a small set of UP activities and artifacts. Some projects will benefit more than others, but, in general, keep it simple. Remember that all UP artifacts are optional, and avoid creating them unless they add value. Focus on early programming, not early documenting.

  customizing UP p. 37

  
  
  

• 由于 UP 是迭代和进化的，因此在实施之前不会完成需求和设计。它们根据反馈通过一系列迭代自适应地出现。

  进化论 A&D 第 25 页

  
  
  

• Since the UP is iterative and evolutionary, requirements and designs are not completed before implementation. They adaptively emerge through a series of iterations, based on feedback.

  evolutionary A&D p. 25

  
  
  

• 将 UML 与敏捷建模实践一起应用。

  敏捷模型 第 30 页

  
  
  

• Apply the UML with agile modeling practices.

  agile models p. 30

  
  
  

• 整个项目没有详细的计划。有一个高级计划（称为阶段计划）来估计项目结束日期和其他主要里程碑，但它没有详细说明这些里程碑的细粒度步骤。详细计划（称为 Iteration Plan）仅提前一个迭代进行更详细的计划。详细规划在迭代之间自适应地完成。

• There isn't a detailed plan for the entire project. There is a high-level plan (called the Phase Plan) that estimates the project end date and other major milestones, but it does not detail the fine-grained steps to those milestones. A detailed plan (called the Iteration Plan) only plans with greater detail one iteration in advance. Detailed planning is done adaptively from iteration to iteration.

案例研究强调相对较少的工件和迭代开发，本着敏捷 UP 的精神。

The case studies emphasize a relatively small number of artifacts, and iterative development, in the spirit of an agile UP.

2.9. 还有其他关键的 UP 实践吗？

2.9. Are There Other Critical UP Practices?

在 UP 中欣赏和实践的中心思想是短时间盒迭代、进化和适应性发展。UP 中的其他一些最佳实践和关键概念：

The central idea to appreciate and practice in the UP is short timeboxed iterative, evolutionary, and adaptive development. Some additional best practices and key concepts in the UP:

• 在早期迭代中解决高风险和高价值问题

• tackle high-risk and high-value issues in early iterations

• 持续吸引用户进行评估、反馈和要求

• continuously engage users for evaluation, feedback, and requirements

• 在早期迭代中构建一个有凝聚力的核心架构

• build a cohesive, core architecture in early iterations

• 持续验证质量;尽早、经常、切合实际地进行测试

• continuously verify quality; test early, often, and realistically

• 在适当的情况下应用用例

• apply use cases where appropriate

• 做一些可视化建模（使用 UML）

• do some visual modeling (with the UML)

• 仔细管理需求

• carefully manage requirements

• 练习更改请求和配置管理

• practice change request and configuration management

2.10. 什么是 UP 阶段？

2.10. What are the UP Phases?

UP 项目将工作和迭代组织为四个主要阶段：

A UP project organizes the work and iterations across four major phases:

这些阶段在后续章节中有更完整的定义。

These phases are more fully defined in subsequent chapters.

这不是旧的 “瀑布” 或顺序生命周期，即首先定义所有需求，然后执行所有或大部分设计。

This is not the old "waterfall" or sequential lifecycle of first defining all the requirements, and then doing all or most of the design.

Inception 不是一个需求阶段;相反，这是一个可行性阶段，在这个阶段，所做的调查刚刚好足以支持继续或停止的决定。

Inception is not a requirements phase; rather, it is a feasibility phase, where just enough investigation is done to support a decision to continue or stop.

同样，细化不是需求或设计阶段;相反，这是一个迭代实现核心架构并缓解高风险问题的阶段。

Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high-risk issues are mitigated.

图 2.6 说明了 UP 中常见的面向进度的术语。请注意，一个开发周期（以系统发布到生产环境结束）由许多迭代组成。

Figure 2.6 illustrates common schedule-oriented terms in the UP. Notice that one development cycle (which ends in the release of a system into production) is composed of many iterations.

图 2.6.Schedule-oriented terms in the UP.

[查看全尺寸图片]

2.11. 什么是 UP 学科？

2.11. What are the UP Disciplines?

UP 描述了学科内的工作活动（例如编写用例）一个主题领域的一组活动（和相关工件），例如需求分析中的活动。在 UP 中，工件是任何工作产品的通用术语：代码、Web 图形、数据库架构、文本文档、图表、模型等。

The UP describes work activities, such as writing a use case, within disciplinesa set of activities (and related artifacts) in one subject area, such as the activities within requirements analysis. In the UP, an artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models, and so on.

UP 有几个学科;本书重点介绍以下三个方面的一些工件：

There are several disciplines in the UP; this book focuses on some artifacts in the following three:

• 业务建模Domain Model 工件，用于可视化应用程序域中值得注意的概念。

• Business Modeling The Domain Model artifact, to visualize noteworthy concepts in the application domain.

• 要求用于捕获功能和非功能需求的 Use-Case Model 和 Supplementary Specification 工件。

• Requirements The Use-Case Model and Supplementary Specification artifacts to capture functional and non-functional requirements.

• 设计Design Model 工件，用于设计软件对象。

• Design The Design Model artifact, to design the software objects.

图 2.7 显示了一个更长的 UP 学科列表。

A longer list of UP disciplines is shown in Figure 2.7.

图 2.7.UP 学科。

[查看全尺寸图片]

在 UP 中，实现意味着对系统进行编程和构建，而不是部署它。环境学科是指为项目建立工具和自定义过程，即设置工具和过程环境。

In the UP, Implementation means programming and building the system, not deploying it. The Environment discipline refers to establishing the tools and customizing the process for the projectthat is, setting up the tool and process environment.

学科和阶段之间的关系是什么？

What is the Relationship Between the Disciplines and Phases?

如图 2.7 所示，在一次迭代期间，大多数或所有学科的工作都在进行。但是，这些学科的相对工作量会随着时间的推移而变化。早期迭代自然倾向于相对强调需求和设计，而后期迭代则不那么重要，因为需求和核心设计通过反馈和适应过程稳定下来。

As illustrated in Figure 2.7, during one iteration work goes on in most or all disciplines. However, the relative effort across these disciplines changes over time. Early iterations naturally tend to apply greater relative emphasis to requirements and design, and later ones less so, as the requirements and core design stabilize through a process of feedback and adaptation.

将此与 UP 阶段（开始、阐述等）联系起来，图 2.8 说明了相对于各个阶段不断变化的相对努力;请注意，这些是暗示性的，而不是字面意思。例如，在细化方面，迭代往往具有相对较高的需求和设计工作水平，尽管肯定也有一些实现。在施工过程中，重点更重于实施，而轻重于需求分析。

Relating this to the UP phases (inception, elaboration, …), Figure 2.8 illustrates the changing relative effort with respect to the phases; please note these are suggestive, not literal. In elaboration, for example, the iterations tend to have a relatively high level of requirements and design work, although definitely some implementation as well. During construction, the emphasis is heavier on implementation and lighter on requirements analysis.

图 2.8.学科和阶段。

[查看全尺寸图片]

书籍结构如何受到 UP 阶段和学科的影响？

How is the Book Structure Influenced by UP Phases and Disciplines?

关于阶段和学科，案例研究的重点是什么？

With respect to the phases and disciplines, what is the focus of the case studies?

前面的章节介绍了 inception 中的活动;后面的章节探讨了阐述中的几次迭代。以下列表和图 2.9 描述了组织在 UP 阶段方面的表现。

The earlier chapters introduce activities in inception; later chapters explore several iterations in elaboration. The following list and Figure 2.9 describe the organization with respect to the UP phases.

图 2.9.书籍组织与 UP 阶段和迭代相关。

[查看全尺寸图片]

2.12. 如何自定义流程？UP 开发案例

2.12. How to Customize the Process? The UP Development Case

UP 中是否有可选的工件或实践？

Are There Optional Artifacts or Practices in the UP?

是的！几乎所有内容都是可选的。也就是说，一些 UP 实践和原则是不变的，例如迭代和风险驱动的开发，以及对质量的持续验证。

Yes! Almost everything is optional. That said, some UP practices and principles are invariant, such as iterative and risk-driven development, and continuous verification of quality.

然而，对 UP 的一个关键见解是，所有活动和工件（模型、图表、文档等）都是可选的，也许不是代码！

However, a key insight into the UP is that all activities and artifacts (models, diagrams, documents, …) are optionalwell, maybe not the code!

定义：什么是开发案例？

Definition: What is the Development Case?

项目的实践和 UP 工件的选择可以写在一个名为 Development Case 的简短文档（环境学科中的工件）中。例如，表 2.1 可能是本书中探讨的“NextGen Project”案例研究的开发案例。

The choice of practices and UP artifacts for a project may be written up in a short document called the Development Case (an artifact in the Environment discipline). For example, Table 2.1 could be the Development Case for the "NextGen Project" case study explored in this book.

后续章节描述了其中一些工件的创建，包括 Domain Model、Use-Case Model 和 Design Model。

Subsequent chapters describe the creation of some of these artifacts, including the Domain Model, Use-Case Model, and Design Model.

本案例研究中介绍的示例实践和工件绝不足以或适合所有项目。例如，机器控制系统可能会从许多状态图中受益。基于 Web 的电子商务系统可能需要关注用户界面原型。“绿地”新开发项目与系统集成项目具有截然不同的设计工件需求。

The example practices and artifacts presented in this case study are by no means sufficient for, or suitable for, all projects. For example, a machine control system may benefit from many state diagrams. A Web-based e-commerce system may require a focus on user interface prototypes. A "green-field" new development project has very different design artifact needs than a systems integration project.

2.13. 你知道你不理解迭代开发或 UP，当时......

2.13. You Know You Didn't Understand Iterative Development or the UP When...

以下是一些迹象，表明您不理解以健康的敏捷精神采用迭代开发和 UP 意味着什么。

Here are some signs that you have not understood what it means to adopt iterative development and the UP in a healthy agile spirit.

• 在开始设计或实现之前，您尝试定义大多数需求。同样，在开始实现之前，您尝试定义大部分设计;在迭代编程和测试之前，您尝试完全定义并提交到架构中。

• You try to define most of the requirements before starting design or implementation. Similarly, you try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing.

• 在编程之前，您花了几天或几周的时间进行 UML 建模，或者您认为 UML 图表和设计活动是全面准确地详细定义设计和模型的时候。您将编程视为将这些代码的简单机械转换。

• You spend days or weeks in UML modeling before programming, or you think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail. And you regard programming as a simple mechanical translation of these into code.

• 您认为 inception = requirements，elaboration = design，construction = implementation（即，将瀑布叠加在 UP 上）。

• You think that inception = requirements, elaboration = design, and construction = implementation (that is, superimposing the waterfall on the UP).

• 您认为细化的目的是全面、仔细地定义模型，并在构建过程中将其转换为代码。

• You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.

• 您认为合适的迭代长度是三个月，而不是三周。

• You believe that a suitable iteration length is three months long, rather than three weeks long.

• 您认为采用 UP 意味着要进行许多可能的活动并创建许多文档，并且您认为或体验 UP 是一个正式的、繁琐的过程，需要遵循许多步骤。

• You think that adopting the UP means to do many of the possible activities and create many documents, and you think of or experience the UP as a formal, fussy process with many steps to be followed.

• 您尝试从头到尾详细规划一个项目;您尝试推测性地预测所有迭代，以及每个迭代中会发生什么。

• You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.

2.14. 历史

2.14. History

有关完整的故事和引文，请参阅“迭代和增量开发：简史”（IEEE Computer，2003 年 6 月，Larman 和 Basili），以及 [Larman03]。迭代方法的历史比许多人意识到的要久远。在 1950 年代后期，进化、迭代和增量开发 （IID），而不是瀑布式，被应用于水星太空项目，在 1960 年代初期，除了许多其他大型系统外，还应用于三叉戟潜艇项目。1968 年，IBM T.J. Watson 研究中心发表了第一篇促进迭代开发而不是瀑布式开发的论文。

For the full story and citations, see "Iterative and Incremental Development: A Brief History" (IEEE Computer, June 2003, Larman and Basili), and also [Larman03]. Iterative methods go back farther than many realize. In the late 1950s, evolutionary, iterative, and incremental development (IID), rather than the waterfall, was applied on the Mercury space project, and in the early 1960s, on the Trident submarine project, in addition to many other large systems. The first published paper promoting iterative rather than waterfall development was published in 1968 at the IBM T.J. Watson Research Center.

IID 在 1970 年代被用于许多大型国防和航空航天项目，包括美国航天飞机飞行控制软件（内置 17 次迭代，平均每次约 4 周）。1970 年代占主导地位的软件工程思想领袖 Harlan Mills 当时写了关于软件项目瀑布式的失败以及 IID 的必要性。私人顾问 Tom Gilb 在 1970 年代创建并发布了 IID Evo 方法，可以说是第一个完全成型的迭代方法。美国国防部在 1970 年代末和 1980 年代初采用了瀑布式标准 （DoD-2167）;到 1980 年代后期，他们经历了重大失败（估计至少 50% 的软件项目被取消或无法使用），因此它被放弃，并最终（从 1987 年开始）被 IID 方法标准取代尽管瀑布影响的遗留问题仍然使一些 DoD 项目感到困惑。

IID was used on many large defense and aerospace projects in the 1970s, including the USA Space Shuttle flight control software (built in 17 iterations averaging about four weeks each). A dominant software engineering thought-leader of the 1970s, Harlan Mills, wrote at that time about the failure of the waterfall for software projects, and the need for IID. Tom Gilb, a private consultant, created and published the IID Evo method in the 1970s, arguably the first fully-formed iterative method. The USA Department of Defense had adopted a waterfall standard in the late 1970s and early 1980s (DoD-2167); by the late 1980s they were experiencing significant failure (estimates of at least 50% of software projects cancelled or unusable), and so it was dropped, and eventually (starting in 1987) replaced by IID method standardsalthough the legacy of waterfall influence still confuses some DoD projects.

同样在 1980 年代，那个年代的主要软件工程思想领袖 Frederick Brooks 博士（以 Mythical Man-Month 闻名）撰写并谈到了瀑布式的缺点以及改用 IID 方法的必要性。1980 年代的另一个里程碑是 Barry Boehm 博士发表了螺旋模型风险驱动的 IID 方法，他指出应用瀑布式时失败的风险很高。

Also in the 1980s, Dr. Frederick Brooks (of Mythical Man-Month fame), a major software engineering thoughtleader of that decade, wrote and spoke about the shortcomings of the waterfall and the need to instead use IID methods. Another 1980s milestone was the publication of the spiral model risk-driven IID method by Dr. Barry Boehm, citing the high risk of failure when the waterfall was applied.

到 1990 年代初期，IID 被广泛认为是瀑布式的继任者，迭代和进化方法如雨后春笋般涌现：UP、DSDM、Scrum、XP 等等。

By the early 1990s, IID was widely recognized as the successor to the waterfall, and there was a flowering of iterative and evolutionary methods: UP, DSDM, Scrum, XP, and many more.

2.15. 推荐资源

2.15. Recommended Resources

对 UP 及其在 RUP 中的改进的可读介绍是 Philippe Kruchten 的 The Rational Unified ProcessAn Introduction。Kruchten 和 Kroll 合著的 The Rational Unified Process Made Easy 也非常出色。

A readable introduction to the UP and its refinement in the RUP is The Rational Unified ProcessAn Introduction by Philippe Kruchten. Also excellent is The Rational Unified Process Made Easy, by Kruchten and Kroll.

敏捷和迭代开发：经理指南 [Larman03] 讨论了迭代和敏捷实践、四种迭代方法（XP、UP、Scrum 和 Evo）、它们背后的证据和历史，以及瀑布失败的证据。

Agile and Iterative Development: A Manager's Guide [Larman03] discusses iterative and agile practices, four iterative methods (XP, UP, Scrum, and Evo), the evidence and history behind them, and the evidence of failure for the waterfall.

对于其他迭代和敏捷方法，推荐使用极限编程 （XP） 系列书籍 [Beck00， BF00， JAH00]，例如 Extreme Programming Explained。本书后面的章节鼓励进行一些 XP 练习。大多数 XP 实践（例如测试驱动编程、持续集成和迭代开发）与 UP 实践兼容或相同，我鼓励在 UP 项目中采用它们。

For other iterative and agile methods, the Extreme Programming (XP) series of books [Beck00, BF00, JAH00] are recommended, such as Extreme Programming Explained. Some XP practices are encouraged in later chapters of this book. Most XP practices (such as test-driven programming, continuous integration, and iterative development) are compatible withor identical toUP practices, and I encourage their adoption on a UP project.

Scrum 方法是另一种流行的迭代方法，它应用 30 天的有时间限制的迭代，每天召开站立会议，每个团队成员回答三个特殊问题。推荐阅读 Agile Software Development with Scrum。

The Scrum method is another popular iterative approach that applies 30-day timeboxed iterations, with a daily stand-up meeting with three special questions answered by each team member. Agile Software Development with Scrum is recommended reading.

Scott Ambler 在 Agile Modeling 中介绍了敏捷建模。

Agile Modeling is described in Agile Modeling, by Scott Ambler.

IBM 销售基于 Web 的在线 RUP 文档产品，该产品提供有关 RUP 工件和活动的全面阅读，以及大多数工件的模板。一个组织可以只使用导师和书籍作为学习资源来运行 UP 项目，但有些人发现 RUP 产品是一种有用的学习和过程辅助工具。

IBM sells the online Web-based RUP documentation product, which provides comprehensive reading on RUP artifacts and activities, and templates for most artifacts. An organization can run a UP project just using mentors and books as learning resources, but some find the RUP product a useful learning and process aid.

对于 Web 资源：

For Web resources:

• www.agilealliance.com收集了许多专门与迭代和敏捷方法相关的文章，以及链接。

• www.agilealliance.com Collects many articles specifically related to iterative and agile methods, plus links.

• www.agilemodeling.com关于敏捷建模的文章。

• www.agilemodeling.com Articles on agile modeling.

• www.cetus-links.orgCetus Links 网站多年来一直专注于对象技术 （OT）。在“OO 项目管理OOA/D 方法”下，它有许多指向迭代和敏捷方法的链接，即使它们与 OT 没有直接关系。

• www.cetus-links.org The Cetus Links site has specialized for years in object technology (OT). Under "OO Project ManagementOOA/D Methods" it has many links to iterative and agile methods, even though they are not directly related to OT.

• www.bradapp.netBrad Appleton 维护着大量有关软件工程的链接，包括迭代方法。

• www.bradapp.net Brad Appleton maintains a large collection of links on software engineering, including iterative methods.

• www.iturls.com中文首页链接到英文版本，搜索引擎引用迭代和敏捷文章。

• www.iturls.com The Chinese front page links to an English version, with a search engine referencing iterative and agile articles.

第 3 章.案例研究

Chapter 3. Case Studies

没有什么比一个好例子更难忍受的了。

马克·吐温

Few things are harder to put up with than a good example.

Mark Twain

介绍

Introduction

选择这些案例研究问题（从第 43 页开始）是因为它们为许多人所熟悉，但又充满了复杂性和有趣的设计问题。这使我们能够专注于学习基本的 OOA/D、需求分析、UML 和模式，而不是解释问题。

These case study problems (starting on p. 43) were chosen because they're familiar to many people, yet rich with complexity and interesting design problems. That allows us to concentrate on learning fundamental OOA/D, requirements analysis, UML and patterns, rather than explaining the problems.

3.1. 案例研究涵盖什么，不涵盖什么？

3.1. What is and isn't Covered in the Case Studies?

通常，应用程序包括 UI 元素、核心应用程序逻辑、数据库访问以及与外部软件或硬件组件的协作。

Generally, applications include UI elements, core application logic, database access, and collaboration with external software or hardware components.

探索其他层（例如 UI 层）的设计将只关注它们与 application logic 层的接口的设计。

Exploring design of the other layers (such as the UI layer) will just focus on the design of their interface to the application logic layer.

为什么在核心应用逻辑层专注于 OOA/D？

Why focus on OOA/D in the core application logic layer?

• 其他层通常非常依赖于技术 / 平台。例如，要探索 Java 中 Web UI 或富客户端 UI 层的 OO 设计，我们需要详细了解 Struts 或 Swing 等框架。但对于 .NET 或 Python，选择和细节非常不同。

• Other layers are usually very technology/platform dependent. For example, to explore the OO design of a Web UI or rich client UI layer in Java, we would need to learn in detail about a framework such as Struts or Swing. But for .NET or Python, the choice and details are very different.

• 相比之下，核心逻辑层的 OO 设计在不同技术中是相似的。

• In contrast, the OO design of the core logic layer is similar across technologies.

• 在应用程序逻辑层的上下文中学到的基本 OO 设计技能适用于所有其他层或组件。

• The essential OO design skills learned in the context of the application logic layer are applicable to all other layers or components.

• 随着新框架或技术的出现，其他层的设计方法/模式往往会迅速变化。例如，在 1990 年代中期，开发人员可能会构建自己的自主开发的对象关系数据库访问层。几年后，他们更有可能使用免费的开源解决方案，例如 Hibernate（如果是 Java 技术）。

• The design approach/patterns for the other layers tends to change quickly as new frameworks or technologies emerge. For example, in the mid-1990s developers would probably build their own home-grown object-relational database access layer. Some years later, they were more likely to use a free, open-source solution such as Hibernate (if Java technology).

图 3.1.在面向对象的系统中对图层和对象进行采样，以及案例研究的重点。

[查看全尺寸图片]

3.2. 案例研究策略：迭代开发 + 迭代学习

3.2. Case Study Strategy: Iterative Development + Iterative Learning

本书的组织方式展示了一个迭代开发策略。OOA/D 应用于多次迭代的案例研究;第一次迭代是针对某些核心函数的。以后的迭代扩展了功能（参见图 3.2）。

This book is organized to show an iterative development strategy. OOA/D is applied to the case studies in multiple iterations; the first iteration is for some core functions. Later iterations expand the functionality (see Figure 3.2).

在迭代开发的同时，分析和设计主题的介绍、UML 表示法和模式以迭代和增量方式引入。在第一次迭代中，提出了一组核心的分析和设计主题和符号。第二次迭代扩展到新思想、UML 表示法和模式。第三次迭代也是如此。

In conjunction with iterative development, the presentation of analysis and design topics, UML notation, and patterns is introduced iteratively and incrementally. In the first iteration, a core set of analysis and design topics and notation is presented. The second iteration expands into new ideas, UML notation, and patterns. And likewise in the third iteration.

3.3. 案例一：NextGen POS 系统

3.3. Case One: The NextGen POS System

第一个案例研究是 NextGen 销售点 （POS） 系统。在这个看似简单的问题域中，我们将看到有有趣的需求和设计问题需要解决。此外，这是一个真正的问题，群体确实使用 Object 技术开发 POS 系统。

The first case study is the NextGen point-of-sale (POS) system. In this apparently straightforward problem domain, we shall see that there are interesting requirement and design problems to solve. In addition, it's a real problemgroups really do develop POS systems with object technologies.

POS 系统是一种计算机化应用程序，（部分）用于记录销售和处理付款;它通常用于零售店。它包括硬件组件，例如计算机和条形码扫描仪，以及用于运行系统的软件。它与各种服务应用程序接口，例如第三方税收计算器和库存控制。这些系统必须具有相对的容错能力;也就是说，即使远程服务暂时不可用（例如库存系统），它们仍然必须能够捕获销售并至少处理现金付款（这样企业就不会瘫痪）。

A POS system is a computerized application used (in part) to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as a third-party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments (so that the business is not crippled).

POS 系统越来越必须支持多种多样的客户端终端和接口。这些设备包括瘦客户端 Web 浏览器终端、具有 Java Swing 图形用户界面的常规个人计算机、触摸屏输入、无线 PDA 等。

A POS system increasingly must support multiple and varied client-side terminals and interfaces. These include a thin-client Web browser terminal, a regular personal computer with something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and so forth.

此外，我们正在创建一个商业 POS 系统，我们将将其出售给在业务规则处理方面具有不同需求的不同客户。在使用该系统的情况下，每个客户都希望在某些可预测的时间点执行一组独特的逻辑，例如当开始新的销售或添加新的行项目时。因此，我们需要一种机制来提供这种灵活性和自定义。

Furthermore, we are creating a commercial POS system that we will sell to different clients with disparate needs in terms of business rule processing. Each client will desire a unique set of logic to execute at certain predictable points in scenarios of using the system, such as when a new sale is initiated or when a new line item is added. Therefore, we will need a mechanism to provide this flexibility and customization.

使用迭代开发策略，我们将进行需求、面向对象的分析、设计和实现。

Using an iterative development strategy, we are going to proceed through requirements, object-oriented analysis, design, and implementation.

3.4. 案例二：大富翁游戏系统

3.4. Case Two: The Monopoly Game System

为了证明 OOA/D 的相同做法可以应用于非常不同的问题，我选择了 Monopoly® 游戏的软件版本作为另一个案例研究。尽管域和需求与 NextGen POS 等业务系统完全不同，但我们将看到域建模、使用模式的对象设计和应用 UML 仍然相关且有用。与 POS 一样，Monopoly 的软件版本是真正开发和销售的，具有丰富的客户端和 Web UI。

To show that the same practices of OOA/D can apply to very different problems, I've chosen a software version of the game of Monopoly® as another case study. Although the domain and requirements are not at all like a business system such as the NextGen POS, we will see that domain modeling, object design with patterns, and applying the UML are still relevant and useful. As with a POS, software versions of Monopoly are truly developed and sold, with both rich client and Web UIs.

我不会重复大富翁的规则;似乎每个国家/地区的几乎每个人在儿童或青少年时期都玩过这个游戏。如果您有任何疑问，可以在许多网站上在线获取这些规则。

I won't repeat the rules for Monopoly; it seems almost every person, in every country, has played this game as a child or teenager. If you have questions, the rules are available online at many websites.

游戏的软件版本将作为模拟运行。一个人将启动游戏并指示模拟玩家的数量，然后观察游戏运行到完成，显示模拟玩家回合期间的活动跟踪。

The software version of the game will run as a simulation. One person will start the game and indicate the number of simulated players, and then watch while the game runs to completion, presenting a trace of the activity during the simulated player turns.

第 2 部分：盗梦空间

Part 2: Inception

第 4 章. Inception is Not the Requirements 阶段

Chapter 4.  Inception is Not the Requirements Phase

第 5 章. 进化要求

Chapter 5.  Evolutionary Requirements

第 6 章. 使用案例

Chapter 6.  Use Cases

第 7 章. 其他要求

Chapter 7.  Other Requirements

第 4 章.Inception is Not the Requirements 阶段

Chapter 4. Inception is Not the Requirements Phase

Le mieux est l'ennemi du bien （最好的是好的敌人）.

伏尔泰

Le mieux est l'ennemi du bien (The best is the enemy of the good).

Voltaire

介绍

Introduction

启动是为项目建立共同愿景和基本范围的最初简短步骤。它将包括对大约 10% 的用例的分析、对关键非功能性需求的分析、业务案例的创建以及开发环境的准备，以便编程可以在下一个细化阶段开始。

Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirement, creation of a business case, and preparation of the development environment so that programming can start in the following elaboration phase.

4.1. 什么是初始计划？

4.1. What is Inception?

大多数项目需要一个简短的初始步骤，其中探讨了以下类型的问题：

Most projects require a short initial step in which the following kinds of questions are explored:

• 这个项目的愿景和商业案例是什么？

• What is the vision and business case for this project?

• 可行？

• Feasible?

• 购买和/或构建？

• Buy and/or build?

• 粗略不可靠的成本范围：是 10K100K 美元还是数百万美元？

• Rough unreliable range of cost: Is it $10K100K or in the millions?

• 我们应该继续还是停止？

• Should we proceed or stop?

定义愿景并获得数量级（不可靠）估计需要进行一些需求探索。但是，启动阶段的目的不是定义所有需求，或生成可信的估计或项目计划。

Defining the vision and obtaining an order-of-magnitude (unreliable) estimate requires doing some requirements exploration. However, the purpose of the inception phase is not to define all the requirements, or generate a believable estimate or project plan.

冒着过于简单化的风险，我们的想法是做足够的调查，以形成对潜在新系统的总体目的和可行性的理性、合理的意见，并决定是否值得投资于更深入的探索（阐述阶段的目的）。

At the risk of over-simplification, the idea is to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system, and decide if it is worthwhile to invest in deeper exploration (the purpose of the elaboration phase).

大多数需求分析发生在细化阶段，与早期生产质量的编程和测试并行进行。

Most requirements analysis occurs during the elaboration phase, in parallel with early production-quality programming and testing.

因此，对于大多数项目来说，启动阶段应该相对较短，例如一周或几周。事实上，在许多项目中，如果它超过一周，那么就错过了开始的重点：决定项目是否值得认真调查（在阐述期间），而不是进行调查。

Thus, the inception phase should be relatively short for most projects, such as one or a few weeks long. Indeed, on many projects, if it is more than a week long, then the point of inception has been missed: It is to decide if the project is worth a serious investigation (during elaboration), not to do that investigation.

这个类比有帮助吗？

Does this Analogy Help?

在石油业务中，当考虑新油田时，一些步骤包括：

In the oil business, when a new field is being considered, some of the steps include:

起始阶段就像这个类比中的第一步。在第一步中，人们不会预测有多少油，或者提取油需要多少成本或精力。虽然能够在没有勘探成本和精力的情况下回答“多少”和“何时”的问题会很好，但在石油业务中，这被认为是不现实的。

The inception phase is like step one in this analogy. In step one people do not predict how much oil there is, or how much cost or effort is needed to extract it. Although it would be nice to be able to answer "how much" and "when" questions without the cost and effort of the exploration, in the oil business it is understood to not be realistic.

用 UP 术语来说，现实的探索步骤是细化阶段。前面的启动阶段类似于可行性研究，以决定是否值得投资勘探钻探。只有经过认真的探索（阐述），我们才能获得数据和洞察力，以做出一些可信的估计和计划。因此，在迭代开发和 UP 中，计划和估计在初始阶段不应被视为可靠。它们只是提供了努力程度的一个数量级的感觉，以帮助决定是否继续。

In UP terms, the realistic exploration step is the elaboration phase. The preceding inception phase is akin to a feasibility study to decide if it is even worth investing in exploratory drilling. Only after serious exploration (elaboration) do we have the data and insight to make somewhat believable estimates and plans. Therefore, in iterative development and the UP, plans and estimates are not to be considered reliable in the inception phase. They merely provide an order-of-magnitude sense of the level of effort, to aid the decision to continue or not.

4.2. 初始计划有多长？

4.2. How Long is Inception?

启动的目的是为项目的目标建立一些初步的共同愿景，确定它是否可行，并决定是否值得在阐述中进行一些认真的调查。如果事先已经决定该项目一定会完成，并且显然是可行的（可能是因为团队以前做过这样的项目），那么启动阶段将特别简短。它可能包括第一次需求研讨会，规划第一次迭代，然后快速进入细化。

The intent of inception is to establish some initial common vision for the objectives of the project, determine if it is feasible, and decide if it is worth some serious investigation in elaboration. If it has been decided beforehand that the project will definitely be done, and it is clearly feasible (perhaps because the team has done projects like this before), then the inception phase will be especially brief. It may include the first requirements workshop, planning for the first iteration, and then quickly moving forward to elaboration.

4.3. Inception 中可以开始哪些工件？

4.3. What Artifacts May Start in Inception?

表 4.1 列出了常见的 inception （或 early elaboration） 工件，并指出了它们解决的问题。后续章节将更详细地研究其中的一些，尤其是 Use-Case Model。关于迭代开发的一个关键见解是要认识到，这些只是在这个阶段部分完成，将在以后的迭代中得到完善，甚至不应该创建，除非认为它们可能会增加真正的实用价值。而且由于它是开始的，调查和工件内容应该是轻量级的。

Table 4.1 lists common inception (or early elaboration) artifacts and indicates the issues they address. Subsequent chapters will examine some of these in greater detail, especially the Use-Case Model. A key insight regarding iterative development is to appreciate that these are only partially completed in this phase, will be refined in later iterations, and should not even be created unless it is deemed likely they will add real practical value. And since it is inception, the investigation and artifact content should be light.

^[]- 这些工件在此阶段仅部分完成。它们将在后续迭代中迭代优化。名称大写意味着正式命名的 UP 工件。

^[] -These artifacts are only partially completed in this phase. They will be iteratively refined in subsequent iterations. Name capitalization implies an officially named UP artifact.

例如，用例模型可能会列出大多数预期用例和参与者的名称，但可能只详细描述了 10% 的用例，这些用例是为了对系统范围、目的和风险进行粗略的高级设想而完成的。

For example, the Use-Case Model may list the names of most of the expected use cases and actors, but perhaps only describe 10% of the use cases in detaildone in the service of developing a rough high-level vision of the system scope, purpose, and risks.

请注意，一些编程工作可能会在开始时进行，以便创建“概念验证”原型，通过（通常）面向 UI 的原型阐明一些需求，以及为关键的“show stopper”技术问题进行编程实验。

Note that some programming work may occur in inception in order to create "proof of concept" prototypes, to clarify a few requirements via (typically) UI-oriented prototypes, and to do programming experiments for key "show stopper" technical questions.

这不是很多文档吗？

Isn't That a Lot of Documentation?

回想一下，工件应该被视为可选。选择只创建那些真正为项目增加价值的，如果它们的价值没有得到证明，就放弃它们。

Recall that artifacts should be considered optional. Choose to create only those that really add value for the project, and drop them if their worth is not proved.

由于这是渐进式开发，因此重点不是在此阶段创建完整的规范，而是初始的、粗略的文档，这些文档在细化迭代期间得到提炼，以响应早期编程和测试的宝贵反馈。

And since this is evolutionary development, the point is not to create complete specifications during this phase, but initial, rough documents, that are refined during the elaboration iterations, in response to the invaluable feedback from early programming and testing.

此外，创建工件或模型的重点通常不是文档或图表本身，而是思考、分析和主动准备。这就是敏捷建模的观点：建模的最大价值是提高理解，而不是记录可靠的规范。正如艾森豪威尔将军所说，“在准备战斗的过程中，我总是发现计划是无用的，但计划是必不可少的”[Nixon90， BF00]。

Also, often the point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness. That's an Agile Modeling perspective: that the greatest value of modeling is to improve understanding, rather than to document reliable specifications. As General Eisenhower said, "In preparing for battle I have always found that plans are useless, but planning indispensable" [Nixon90, BF00].

另请注意，以前项目中的工件可以在以后的项目上部分重用。跨项目在风险、项目管理、测试和环境工件方面存在许多相似之处，这是很常见的。所有 UP 项目都应以相同的方式组织工件，并使用相同的名称（Risk List、Development Case 等）。这简化了从新活动中先前项目中查找可重用的项目的过程。

Note also that artifacts from previous projects can be partially reused on later ones. It is common for there to be many similarities in risk, project management, testing, and environment artifacts across projects. All UP projects should organize artifacts the same way, with the same names (Risk List, Development Case, and so on). This simplifies finding reusable artifacts from prior projects on new engagements.

4.4. 你知道你不理解 Inception 的时候......

4.4. You Know You Didn't Understand Inception When...

• 对于大多数项目来说，它不仅仅是 “几个” 星期。

• It is more than "a few" weeks long for most projects.

• 尝试定义大多数要求。

• There is an attempt to define most of the requirements.

• 预计估计或计划是可靠的。

• Estimates or plans are expected to be reliable.

• 您定义架构（这应该在细化中迭代完成）。

• You define the architecture (this should be done iteratively in elaboration).

• 您认为正确的工作顺序应该是：1） 定义需求;2） 设计架构;3） 实施。

• You believe that the proper sequence of work should be: 1) define the requirements; 2) design the architecture; 3) implement.

• 没有业务案例或愿景工件。

• There is no Business Case or Vision artifact.

• 所有用例都编写得很详细。

• All the use cases were written in detail.

• 没有一个用例被详细编写;相反，应该详细编写 1020%，以便对问题的范围有一些现实的了解。

• None of the use cases were written in detail; rather, 1020% should be written in detail to obtain some realistic insight into the scope of the problem.

4.5. 开始时有多少 UML？

4.5. How Much UML During Inception?

启动的目的是收集足够的信息来建立共同的愿景，决定向前推进是否可行，以及该项目是否值得在制定阶段进行认真调查。因此，也许除了简单的 UML 用例图之外，不需要太多的图表。在开始时，我们更注重理解基本范围和 10% 的需求，主要以文本形式表示。在实践中，因此在本演示中，大多数 UML 图将发生在下一阶段阐述中。

The purpose of inception is to collect just enough information to establish a common vision, decide if moving forward is feasible, and if the project is worth serious investigation in the elaboration phase. As such, perhaps beyond simple UML use case diagrams, not much diagramming is warranted. There is more focus in inception on understanding the basic scope and 10% of the requirements, expressed mostly in text forms. In practice, and thus in this presentation, most UML diagramming will occur in the next phaseelaboration.

第 5 章.进化要求

Chapter 5. Evolutionary Requirements

在我们的世界里，人们不知道自己想要什么，并愿意经历地狱来得到它。

唐·马奎斯

Ours is a world where people don't know what they want and are willing to go through hell to get it.

Don Marquis